https://bugs.freedesktop.org/show_bug.cgi?id=90355
higu...@gmx.net changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=102641
Bug ID: 102641
Summary: amdgpu: Oops when setting battery profile on a RX480
Product: DRI
Version: XOrg git
Hardware: Other
OS: All
Status: NEW
Severity:
https://bugs.freedesktop.org/show_bug.cgi?id=91880
Thomas DEBESSE changed:
What|Removed |Added
Attachment #134124|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #167 from Thomas DEBESSE ---
Created attachment 134124
--> https://bugs.freedesktop.org/attachment.cgi?id=134124&action=edit
kernel patch: set "high" default DPM profile instead of "auto" for 0x67B1
variant
So, using my 0x67B0 vari
https://bugs.freedesktop.org/show_bug.cgi?id=102500
charlie changed:
What|Removed |Added
CC||bug0xa...@hushmail.com
--- Comment #21 from c
https://bugs.freedesktop.org/show_bug.cgi?id=102500
--- Comment #20 from charlie ---
I confirm that bug 102500 and bug 102598 are the same.
I split up the patch into 3 parts and they applied cleanly with offsets to
drm-next-4.15-wip.
I then reverted mesa to commit 214b565bc28bc4419f3eec29ab7bbe
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #166 from garththei...@hotmail.com ---
As does mine, my dmesg ...
[drm] initializing kernel modesetting (HAWAII 0x1002:0x67B1 0x1682:0x9390
0x80).
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #165 from Thomas DEBESSE ---
Note that all joined dmesg reports a HAWAII 0x1002:0x67B1 PCI ID except mine
reporting a HAWAII 0x1002:0x67B0 PCI ID (I also checked the dmesg joined in
duplicates of this bug). So the subset seems to be w
https://bugs.freedesktop.org/show_bug.cgi?id=102637
Michel Dänzer changed:
What|Removed |Added
QA Contact|xorg-t...@lists.x.org |
Version|7.7 (2012.06)
https://bugs.freedesktop.org/show_bug.cgi?id=101229
--- Comment #18 from Michel Dänzer ---
(In reply to Justin Mitzel from comment #16)
> I also figured that posting here would be better than making a new bug
> report.
I'm afraid that was the wrong call, please file your own report.
In genera
Em Sat, 9 Sep 2017 17:27:06 +0200
Wolfram Sang escreveu:
> > Yes, but the statistics that 10% of I2C bus master drivers
> > are DMA-safe is not true, if you take those into account ;-)
> >
> > Perhaps you could write it as (or something similar):
> >
> > At this time of writing, only +10% o
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #164 from Thomas DEBESSE ---
(In reply to Jon Doane from comment #159)
> I've literally been doing:
> "echo high > /sys/class/device/drm/card0/power_dpm_force_performance_level"
> every day to boot my machine for over a year
See com
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #163 from Thomas DEBESSE ---
> It seems tied to a small subset of 390s.
Many precise models were listed. It's easy to get one of them.
For example this one is known to be buggy:
https://www.amazon.com/dp/B00ZGF158A/
It's weird if AM
https://bugs.freedesktop.org/show_bug.cgi?id=101229
--- Comment #17 from Paul ---
> https://vid.me/n0t1r
Ok, that 'tearing' is in fact much different to what I've been seeing, in your
case it looks a lot more like *corruption* as entire chunks of buffer are being
rendered in random offset posit
On 09/08/2017 10:07 AM, Noralf Trønnes wrote:
No need to put out a driver registered message since drm_dev_register()
does that now. SPI speed is an important metric when dealing with
display problems, so retain that info.
Cc: David Lechner
Signed-off-by: Noralf Trønnes
---
Acked-by: David L
Hi Hoegeun,
[auto build test ERROR on robh/for-next]
[also build test ERROR on v4.13 next-20170908]
[cannot apply to drm-exynos/exynos-drm/for-next]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commit
https://bugs.freedesktop.org/show_bug.cgi?id=102500
--- Comment #19 from charlie ---
Bug 102500 might be related to bug 102598.
I tried to apply patch attachment 134082 to amd-staging-4.12 (~agd5f/linux)
kernel and drm-next-4.15-wip but it does not apply cleanly. I applied it
manually to drm-n
https://bugs.freedesktop.org/show_bug.cgi?id=102500
--- Comment #18 from Vedran Miletić ---
(In reply to Arek Ruśniak from comment #16)
> Patch fixes issue.
> I've tried both staging-4.12 and staging-drm-next branches.
> Thanks Christian
>
> PS. It will be nice if Vedran could confirmed this for
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #162 from Chris Waters ---
One of the issues I've seen mentioned by one of the AMD guys on Reddit
(/u/bridgmanAMD) is that they have been unable to reproduce the issue. It
seems tied to a small subset of 390s.
--
You are receiving
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #161 from garththei...@hotmail.com ---
Not sure how well a bug bounty might work for this issue, but would there be
any interest? Maybe a fund for hardware purchase (R9 390) to send to someone
with the expertise to diagnose/fix work ag
https://bugs.freedesktop.org/show_bug.cgi?id=101229
--- Comment #16 from Justin Mitzel ---
(In reply to Michel Dänzer from comment #14)
> How do you know it's the same problem? I still don't have a good idea what
> the problem reported here looks like (and my last questions from comment 12
> are
Den 04.09.2017 09.59, skrev Jyri Sarha:
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
On 08/13/17 16:32, Noralf Trønnes wrote:
drm_fb_cma_create() is just a wrapper around drm_gem_fb_create() now,
so use the func
https://bugs.freedesktop.org/show_bug.cgi?id=102638
--- Comment #3 from mj.wilson...@gmail.com ---
Created attachment 134116
--> https://bugs.freedesktop.org/attachment.cgi?id=134116&action=edit
Tacoma render
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=102638
--- Comment #2 from mj.wilson...@gmail.com ---
Created attachment 134115
--> https://bugs.freedesktop.org/attachment.cgi?id=134115&action=edit
Unigine Superposition render 2
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=102638
--- Comment #1 from mj.wilson...@gmail.com ---
Created attachment 134114
--> https://bugs.freedesktop.org/attachment.cgi?id=134114&action=edit
Unigine Superposition render 1
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=102638
Bug ID: 102638
Summary: Incorrect rendering in OpenGL 4 (Unigine Superposition
+ others)
Product: Mesa
Version: 17.1
Hardware: x86-64 (AMD64)
OS: Linux (Al
Hi,
On Fri, Sep 08, 2017 at 03:50:12PM +0800, Chen-Yu Tsai wrote:
> The device tree binding for sun4i-drm says:
>
> For all connections between components up to the TCONs in the display
> pipeline, when there are multiple components of the same type at the
> same depth, the local endp
Hi,
On Fri, Sep 08, 2017 at 03:50:08PM +0800, Chen-Yu Tsai wrote:
> Hi everyone,
>
> Previously I added support for two display pipelines for the sun4i-drm
> driver. At the time we did not have support for downstream encoders to
> actually test the second pipeline, nor having both pipelines activ
> Yes, but the statistics that 10% of I2C bus master drivers
> are DMA-safe is not true, if you take those into account ;-)
>
> Perhaps you could write it as (or something similar):
>
> At this time of writing, only +10% of I2C bus master
> drivers for non-remote boards have DMA supp
https://bugs.freedesktop.org/show_bug.cgi?id=99319
Bas Nieuwenhuizen changed:
What|Removed |Added
Resolution|--- |FIXED
Component|Drivers/Vul
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #160 from Stefan ---
Jon Doane, to alleviate your pains, set radeon.dpm=0 as a boot option.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing l
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #159 from Jon Doane ---
Is there going to be any work on this? I've literally been doing:
"echo high > /sys/class/device/drm/card0/power_dpm_force_performance_level"
every day to boot my machine for over a year hoping that this might
https://bugs.freedesktop.org/show_bug.cgi?id=102633
Bug ID: 102633
Summary: Running ConeStepMap in wine freezes the system
Product: Mesa
Version: git
Hardware: Other
OS: All
Status: NEW
Severity: normal
On Fri, Sep 08, 2017 at 09:46:27PM +0200, Daniel Vetter wrote:
> On Fri, Sep 08, 2017 at 09:40:39PM +0200, Maxime Ripard wrote:
> > sun4i-drm is maintained in drm-misc as a small driver.
> >
> > Signed-off-by: Maxime Ripard
>
> Reviewed-by: Daniel Vetter
Applied. Let's see if pushing patches w
Em Fri, 8 Sep 2017 10:56:40 +0200
Wolfram Sang escreveu:
> Hi Mauro,
>
> thanks for your comments. Much appreciated!
>
> > There are also a couple of things here that Sphinx would complain.
> > So, it could be worth to rename it to *.rst, while you're writing
> > it, and see what:
> > make
On Fri, Sep 8, 2017 at 8:02 AM, Hoegeun Kwon wrote:
> Currently, the compatible('samsung,exynos5-gsc') is not used.
> Remove unnecessary compatible.
>
> Signed-off-by: Hoegeun Kwon
> ---
> Documentation/devicetree/bindings/media/exynos5-gsc.txt | 8
> 1 file changed, 4 insertions(+), 4
On Thu, Aug 24, 2017 at 03:33:59PM +0200, Andrzej Hajda wrote:
> Since i80/command mode is determined in runtime by propagating info
> from panel this property can be removed.
>
> Signed-off-by: Andrzej Hajda
> ---
> arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi | 6 --
> 1 file chan
This commit adds support for Mitsubishi aa070mc01 TFT panel working
with 8 bit ISP mode (pin 19 "mode" HIGH for 20 pin TFT connector).
Signed-off-by: Lukasz Majewski
---
drivers/gpu/drm/panel/panel-simple.c | 35 +++
1 file changed, 35 insertions(+)
diff --git a/
On Tue, Sep 05, 2017 at 04:01:38PM +0200, Maciej Purski wrote:
> SiI9234 transmitter converts eTMDS/HDMI signal to MHL 1.0.
> It is controlled via I2C bus. Its interaction with other
> devices in video pipeline is performed mainly on HW level.
> The only interaction it does on device driver level i
This patch is ported from linux stable 4.9, commit
3587c856675c45809010c2cee5b21096f6e8e938.
So I think I don't need to port on version 4.9.
On 9/8/2017 2:21 PM, Greg KH wrote:
On Fri, Sep 08, 2017 at 09:46:02AM +0700, Nhan Nguyen wrote:
commit 3587c856675c45809010c2cee5b21096f6e8e938 upstream
https://bugs.freedesktop.org/show_bug.cgi?id=101229
--- Comment #15 from Michel Dänzer ---
(In reply to Paul from comment #0)
> Has affected mesa 12 and kernel 4.8 onwards.
BTW, Paul, does this mean that the problem doesn't occur if you use Mesa < 12
or kernel < 4.8? If so, can you bisect Mesa o
41 matches
Mail list logo