https://bugs.freedesktop.org/show_bug.cgi?id=105733
--- Comment #27 from Suloev Dmitry ---
Looks like all my problems fixed in latest kernel. Thx!
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-
From: Koji Matsuoka
This patch adds the option to specify a maximal clock and a minimal vertical
refresh rate.
Signed-off-by: Koji Matsuoka
[uli: renamed properties, fixed transposed parsing]
Signed-off-by: Ulrich Hecht
---
drivers/gpu/drm/bridge/adv7511/adv7511.h | 7 +++
drivers/gp
On 2018-08-14 16:33, Rob Herring wrote:
> On Tue, Aug 14, 2018 at 12:36 AM Peter Rosin wrote:
>>
>> On 2018-08-13 22:52, Rob Herring wrote:
>>> On Mon, Aug 13, 2018 at 8:25 AM Peter Rosin wrote:
On 2018-08-13 15:59, jacopo mondi wrote:
> Hi Peter,
>
> On Fri, Aug 10, 2018 at
On Tue, Aug 14, 2018 at 04:36:03PM +0200, Alexandre Belloni wrote:
> On 13/08/2018 20:18:08+0200, Sam Ravnborg wrote:
> > > Would be good to have a plan to phase-out the old atmel_lcdfb fbdev
> > > driver when this one addresses some TODO items that make sense.
> > Agree on this.
> > One approach c
From: Koji Matsuoka
Signed-off-by: Koji Matsuoka
---
drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
index b52b3e8..cd6803a 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_cr
From: Marcel Ziswiler
Actually report the error code from devm_regulator_get() unless it
is just a probe deferral.
Signed-off-by: Marcel Ziswiler
---
Changes in v2:
- Silence probe deferral as suggested by Lucas.
- Fix line over 80 characters as reported by checkpatch.
drivers/gpu/drm/tegra
In R-Car D3 and E3, the DU dot clock can be sourced from the LVDS PLL.
This patch enables that PLL if present.
Based on patch by Koji Matsuoka .
Signed-off-by: Ulrich Hecht
---
drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 3 +
drivers/gpu/drm/rcar-du/rcar_du_crtc.h | 2 +
drivers/gpu/drm/rc
Hi Rob.
Thanks for the feedback, as I am rather new to this DT stuff
a few iterations are no suprise.
> > If I understand the proposal from you correct an example binding would
> > look like this:
> >
> >lcdc0: lcdc@70 {
> > compatible = "atmel,at91sam9263-lcdc";
> >
The "atomic" API allows us to configure PWM period and duty_cycle and
enable it in one call.
The patch also moves the pwm_init_state just before any use of the
pwm_state struct, this fixes a potential bug where pwm_get_state
can be called before pwm_init_state.
Signed-off-by: Enric Balletbo i Ser
From: Koji Matsuoka
This patch adds D3 definition for DU and fixes digital RGB routing.
Signed-off-by: Koji Matsuoka
---
drivers/gpu/drm/rcar-du/rcar_du_drv.c | 3 ++-
drivers/gpu/drm/rcar-du/rcar_du_drv.h | 2 ++
drivers/gpu/drm/rcar-du/rcar_du_group.c | 4
3 files changed, 8 inserti
On 13/08/2018 20:18:08+0200, Sam Ravnborg wrote:
> > Would be good to have a plan to phase-out the old atmel_lcdfb fbdev
> > driver when this one addresses some TODO items that make sense.
> Agree on this.
> One approach could be to say that when all in-kernel users of atmel_lcdfb
> are ported, the
Adds LVDS decoder, HDMI encoder and connector for Draak boards.
Signed-off-by: Ulrich Hecht
Reviewed-by: Laurent Pinchart
---
arch/arm64/boot/dts/renesas/r8a77995-draak.dts | 84 ++
1 file changed, 84 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a77995-draak
Add support for the R-Car D3 (R8A77995) SoC to the R-Car DU driver.
Based on patch by Koji Matsuoka .
Signed-off-by: Ulrich Hecht
---
drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 17 ++---
drivers/gpu/drm/rcar-du/rcar_du_drv.c | 26 ++
drivers/gpu/drm/rcar-du/
On Tue, Aug 14, 2018 at 10:21:29AM +0200, Daniel Vetter wrote:
> On Mon, Aug 13, 2018 at 11:04:11PM +0300, Haneen Mohammed wrote:
> > On Wed, Aug 08, 2018 at 10:23:27AM +0200, Daniel Vetter wrote:
> > > On Wed, Aug 08, 2018 at 06:53:17AM +0300, Haneen Mohammed wrote:
> > > > On Tue, Aug 07, 2018 at
Hi Daniel.
> > rename drivers/gpu/drm/{atmel-hlcdc => atmel}/atmel_hlcdc_plane.c (100%)
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 96e98e206b0d..09ce76a9a1dc 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -4681,7 +4681,7 @@ DRM DRIVERS FOR ATMEL HLCDC
> > M: Boris Brezi
From: Kieran Bingham
The r8a77995 D3 platform has 2 LVDS channels connected to the DU.
Signed-off-by: Kieran Bingham
[uli: moved lvds* into the soc node, added PM domains, resets]
Signed-off-by: Ulrich Hecht
Reviewed-by: Laurent Pinchart
---
arch/arm64/boot/dts/renesas/r8a77995.dtsi | 56 +++
From: Jacopo Mondi
The processor manual prescribes to clear reset of LVDS interface in CPG/MSSR
module before display on, and to assert the same reset line at display off
time, to have the module resuming in a known state.
The module is said to be in "standby state" at initialization time, and t
Hi Rob.
> I don't know that 2 registers for a backlight PWM constitute an MFD. A
> single node can be both an LCD controller and a PWM.
Current suggestion from v1 patchset looks like this:
lcdc0: lcdc@70 {
compatible = "atmel,at91sam9263-lcdc-mfd";
reg
Hi!
This is a prototype extension of the series "R-Car D3 LVDS/HDMI support"
that includes an up-port of the LVDS PLL support in the BSP.
While this is prototype-quality code, there are in my judgment no serious
hacks in it. The most significant deviation in behavior between this and
the BSP cod
From: Koji Matsuoka
This patch corrects that the extal clock used with the fixed value
is acquired from the device tree.
Also, it is possible to select extal or dotclkin for R8A77995 and
R8A77990. This patch adds its selection procedure.
Signed-off-by: Koji Matsuoka
---
drivers/gpu/drm/rcar-du
On Tue, Aug 14, 2018 at 09:52:33PM +0200, Daniel Vetter wrote:
> On Tue, Aug 14, 2018 at 9:03 PM, Haneen Mohammed
> wrote:
> > On Tue, Aug 14, 2018 at 10:21:29AM +0200, Daniel Vetter wrote:
> >> On Mon, Aug 13, 2018 at 11:04:11PM +0300, Haneen Mohammed wrote:
> >> > On Wed, Aug 08, 2018 at 10:23:2
From: Koji Matsuoka
Signed-off-by: Koji Matsuoka
Signed-off-by: Takeshi Kihara
Signed-off-by: Ulrich Hecht
---
arch/arm64/boot/dts/renesas/r8a77995-draak.dts | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
b/arch/arm6
These codes are not used.
Signed-off-by: Huang Rui
---
drivers/gpu/drm/ttm/ttm_bo_util.c| 5 +
drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 8 +---
2 files changed, 2 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
b/drivers/gpu/drm/ttm/ttm_bo_util.c
Am 15.08.2018 um 09:41 schrieb Huang Rui:
These codes are not used.
Signed-off-by: Huang Rui
Reviewed-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo_util.c| 5 +
drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 8 +---
2 files changed, 2 insertions(+), 11 deletions(-)
di
https://bugs.freedesktop.org/show_bug.cgi?id=107572
--- Comment #1 from Michel Dänzer ---
Can you try latest Mesa / LLVM?
Please attach the corresponding Xorg log file and output of dmesg.
--
You are receiving this mail because:
You are the assignee for the bug.
Hi Sam,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on at91/at91-next]
[also build test WARNING on v4.18 next-20180814]
[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/linu
https://bugs.freedesktop.org/show_bug.cgi?id=107572
--- Comment #2 from madc...@atlas.cz ---
I remember I tried with an RC of mesa 18.2 and kernel 4.18-rc6 which didn't
help in any way. If you want me to try the latest code from git/SVN I'll see
what I can do (I can't exactly mess up my production
On 14/08/18 17:17, Daniel Vetter wrote:
> On Mon, Feb 26, 2018 at 8:52 AM, Jyri Sarha wrote:
>> On 25/02/18 11:22, Lukas Wunner wrote:
>>> On Thu, Feb 22, 2018 at 07:42:46PM +0200, Jyri Sarha wrote:
Put consumer device to deferred probe list if it is unbound due to a
dropped link to a su
This adds the possibility to test arbitrary enumerations in IGT without
having to define mappings for each and every one.
Changes since v1:
- Add commit description.
- Add try_prop_enum, to allow handling unknown enumerations.
Signed-off-by: Maarten Lankhorst
---
lib/igt_kms.c | 90
Signed-off-by: Maarten Lankhorst
---
lib/igt_kms.c | 2 +
lib/igt_kms.h | 2 +
tests/Makefile.sources| 1 +
tests/kms_plane_alpha_blend.c | 561 ++
tests/meson.build | 1 +
5 files changed, 567 insertions(
We now have infrastructure for generic enum handling. This will make it easier
to write new tests without defining all enum constants beforehand.
Signed-off-by: Maarten Lankhorst
---
lib/igt_color_encoding.c | 19 ++
lib/igt_color_encoding.h | 3 ++
lib/igt_kms.c| 77 +--
On Wed, Aug 15, 2018 at 09:49:58AM +0300, Jyri Sarha wrote:
> On 14/08/18 17:17, Daniel Vetter wrote:
> > On Mon, Feb 26, 2018 at 8:52 AM, Jyri Sarha wrote:
> >> On 25/02/18 11:22, Lukas Wunner wrote:
> >>> On Thu, Feb 22, 2018 at 07:42:46PM +0200, Jyri Sarha wrote:
> Put consumer device to d
https://bugs.freedesktop.org/show_bug.cgi?id=107560
--- Comment #2 from Michel Dänzer ---
Please attach the corresponding dmesg output.
Do things work better with xf86-video-amdgpu instead of the modesetting Xorg
driver?
The gnome-shell crash is probably a gnome-shell / mutter bug.
--
You are
https://bugs.freedesktop.org/show_bug.cgi?id=107559
Michel Dänzer changed:
What|Removed |Added
Product|xorg|DRI
Assignee|xorg-driver-...@
This adds the possibility to test arbitrary enumerations in IGT without
having to define mappings for each and every one.
Changes since v1:
- Add commit description.
- Add try_prop_enum, to allow handling unknown enumerations.
Signed-off-by: Maarten Lankhorst
---
lib/igt_kms.c | 90
Add a few tests to test various blending modes.
Some of the tests will skip if pixel mode alpha cannot be enabled
with plane alpha at the same time. This is for mali-dp. I didn't
test on that platform, but tested with the same check on i915.
The tests won't pass i915 on pre-gen11 hw. i915 has sma
We now have infrastructure for generic enum handling. This will make it easier
to write new tests without defining all enum constants beforehand.
Changes since v1:
- Fix compile error, sent old version by accident.
Signed-off-by: Maarten Lankhorst
---
lib/igt_color_encoding.c | 20 +++
On Wed, Aug 15, 2018 at 02:35:32PM +0800, Lowry Li wrote:
> Pixel blend modes represent the alpha blending equation
> selection, describing how the pixels from the current
> plane are composited with the background.
>
> Adds a pixel_blend_mode to drm_plane_state and a
> blend_mode_property to drm_
On Wed, Aug 15, 2018 at 02:35:33PM +0800, Lowry Li wrote:
> Checks the pixel blending mode and plane alpha value when
> do the plane_check. Mali DP supports blending the current plane
> with the background either based on the pixel alpha blending
> mode or by using the layer's alpha value, but not
On Wed, 15 Aug 2018, Paul Wise wrote:
> Hi all,
>
> I noticed that the drm cmdline EDID override mechanisms no longer work
> since Linux version 4.15.
Please file a bug over at [1], describe the symptomps of how it doesn't
work (black screen, wrong mode, what?), add drm.debug=14 module
parameter,
Add plane alpha blending support with the different blend modes.
This has been tested on a icl to show the correct results,
on earlier platforms small rounding errors cause issues. But this
already happens case with fully transparant or fully opaque RGB
fb's.
The recommended HW workaround is t
From: Michel Dänzer
Fixes: "drm/scheduler: rename gpu_scheduler.c to sched_main.c"
Signed-off-by: Michel Dänzer
---
Documentation/gpu/drm-mm.rst | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst
index 21b6b72a9ba8
Am 15.08.2018 um 12:58 schrieb Michel Dänzer:
From: Michel Dänzer
Fixes: "drm/scheduler: rename gpu_scheduler.c to sched_main.c"
Signed-off-by: Michel Dänzer
Ah, of course. I knew that I've forgotten something.
Patch is Reviewed-by: Christian König
Thanks,
Christian.
---
Documentation
On Thu, Jul 26, 2018 at 03:10:04PM +0100, Alexandru Gheorghe wrote:
> Some drivers can't use drm_gem_fb_create, so instead of copying the
> logic that does the framebuffer allocation allow them to use core
> drm_gem_fb_alloc.
>
> Signed-off-by: Alexandru Gheorghe
To me it looks like an useful th
On Wed, Aug 15, 2018 at 12:08:38PM +0100, Liviu Dudau wrote:
> On Thu, Jul 26, 2018 at 03:10:04PM +0100, Alexandru Gheorghe wrote:
> > Some drivers can't use drm_gem_fb_create, so instead of copying the
> > logic that does the framebuffer allocation allow them to use core
> > drm_gem_fb_alloc.
> >
https://bugs.freedesktop.org/show_bug.cgi?id=107552
--- Comment #6 from Christian König ---
Created attachment 141104
--> https://bugs.freedesktop.org/attachment.cgi?id=141104&action=edit
Possible fix
The attached patch should fix the issue, please test.
--
You are receiving this mail becaus
https://bugs.freedesktop.org/show_bug.cgi?id=107580
Bug ID: 107580
Summary: [amdgpu] Firefox can force driver into a crash (AMD
Radeon HD 8600M HANIAN)
Product: DRI
Version: XOrg git
Hardware: Other
OS: All
Den 14.08.2018 10.57, skrev Hean-Loong, Ong:
From: Ong Hean Loong
Driver for Intel FPGA Video and Image Processing Suite Frame Buffer II.
The driver only supports the Intel Arria10 devkit and its variants.
This driver can be either loaded staticlly or in modules.
The OF device tree binding is
On Wed, Aug 15, 2018 at 01:54:12PM +0200, Daniel Vetter wrote:
> On Wed, Aug 15, 2018 at 12:08:38PM +0100, Liviu Dudau wrote:
> > On Thu, Jul 26, 2018 at 03:10:04PM +0100, Alexandru Gheorghe wrote:
> > > Some drivers can't use drm_gem_fb_create, so instead of copying the
> > > logic that does the f
https://bugs.freedesktop.org/show_bug.cgi?id=107581
Bug ID: 107581
Summary: Graphics Not Rendered Due to Missing 4.5 COMPAT
Profile
Product: Mesa
Version: git
Hardware: x86-64 (AMD64)
OS: Linux (All)
https://bugs.freedesktop.org/show_bug.cgi?id=107581
--- Comment #1 from Benjamin Hodgetts ---
Created attachment 141110
--> https://bugs.freedesktop.org/attachment.cgi?id=141110&action=edit
APITrace
~900MB uncompressed.
--
You are receiving this mail because:
You are the assignee for the bug
https://bugs.freedesktop.org/show_bug.cgi?id=107552
--- Comment #7 from Sylvain BERTRAND ---
I applied on top of commit 1e12c16d7697a1223630a507c1032d940794039a
Stable so far.
--
You are receiving this mail because:
You are the assignee for the bug._
On Wed, 08 Aug 2018, Keith Packard wrote:
> This parameter allows the set of EDID quirks to be changed at
> runtime. The syntax is
>
> vendor/product/quirks,vendor/product/quirks,...
>
> where vendor is the three-letter EDID vendor value, product is the
> EDID product id which may be prefixe
https://bugs.freedesktop.org/show_bug.cgi?id=107581
--- Comment #2 from Karol Herbst ---
when replaying the trace I see some compilation issues:
227035: message: major shader compiler error 2: 0:25(25): error: no matching
function for call to `texture2DLod(sampler2D, vec2, float)'; candidates ar
On Wed, Aug 15, 2018 at 2:27 PM, Alexandru-Cosmin Gheorghe
wrote:
> On Wed, Aug 15, 2018 at 01:54:12PM +0200, Daniel Vetter wrote:
>> On Wed, Aug 15, 2018 at 12:08:38PM +0100, Liviu Dudau wrote:
>> > On Thu, Jul 26, 2018 at 03:10:04PM +0100, Alexandru Gheorghe wrote:
>> > > Some drivers can't use
https://bugs.freedesktop.org/show_bug.cgi?id=107581
--- Comment #3 from Karol Herbst ---
and there are some 0:1294(3): preprocessor error: Unterminated #if
I think this is mostly due to uncompiled shaders, maybe there is more to it,
but we should concentrate on those issues first.
--
You are r
Applied. thanks!
Alex
From: kbuild test robot
Sent: Wednesday, August 15, 2018 12:45:08 AM
To: Xu, Feifei
Cc: kbuild-...@01.org; dri-devel@lists.freedesktop.org; Deucher, Alexander;
Zhang, Hawking
Subject: [RFC PATCH radeon-alex] drm/amdgpu: nbio_v7_4_hdp_flus
On Wed, Aug 15, 2018 at 01:02:25PM +0200, Christian König wrote:
> Am 15.08.2018 um 12:58 schrieb Michel Dänzer:
> > From: Michel Dänzer
> >
> > Fixes: "drm/scheduler: rename gpu_scheduler.c to sched_main.c"
> > Signed-off-by: Michel Dänzer
>
> Ah, of course. I knew that I've forgotten somethin
Am 15.08.2018 um 15:42 schrieb Daniel Vetter:
On Wed, Aug 15, 2018 at 01:02:25PM +0200, Christian König wrote:
Am 15.08.2018 um 12:58 schrieb Michel Dänzer:
From: Michel Dänzer
Fixes: "drm/scheduler: rename gpu_scheduler.c to sched_main.c"
Signed-off-by: Michel Dänzer
Ah, of course. I knew
On Wed, Aug 15, 2018 at 03:54:52PM +0200, Christian König wrote:
> Am 15.08.2018 um 15:42 schrieb Daniel Vetter:
> > On Wed, Aug 15, 2018 at 01:02:25PM +0200, Christian König wrote:
> > > Am 15.08.2018 um 12:58 schrieb Michel Dänzer:
> > > > From: Michel Dänzer
> > > >
> > > > Fixes: "drm/schedul
On Tue, Aug 14, 2018 at 06:50:59PM +0200, Enric Balletbo i Serra wrote:
> The "atomic" API allows us to configure PWM period and duty_cycle and
> enable it in one call.
>
> The patch also moves the pwm_init_state just before any use of the
> pwm_state struct, this fixes a potential bug where pwm_g
https://bugs.freedesktop.org/show_bug.cgi?id=102322
--- Comment #40 from Andrey Grodzovsky ---
Created attachment 141112
--> https://bugs.freedesktop.org/attachment.cgi?id=141112&action=edit
.config
I uploaded my .config file - maybe something in your Kconfig flags makes this
happen - you can
https://bugs.freedesktop.org/show_bug.cgi?id=106529
--- Comment #2 from Michel Dänzer ---
(In reply to Mariusz Mazur from comment #1)
> Pre-DC codepaths did not have an issue like this at all until Michel Dänzer
> created this patch: https://patchwork.freedesktop.org/patch/209464/ for bug
> 10530
On Tue, Aug 14, 2018 at 10:48 PM Sam Ravnborg wrote:
>
[...]
> > > One DT related Q:
> > > The LCD Controller supports BGR565, but as this is less common some HW
> > > implmentations
> > > exchange R and B, expessed in the old binding as wiring-mode like this:
> > >
> > > atmel,lcd-wiring-m
On Wed, Aug 15, 2018 at 4:45 PM, Rob Herring wrote:
> On Tue, Aug 14, 2018 at 10:48 PM Sam Ravnborg wrote:
>>
>
> [...]
>
>> > > One DT related Q:
>> > > The LCD Controller supports BGR565, but as this is less common some HW
>> > > implmentations
>> > > exchange R and B, expessed in the old bind
On Tue, Aug 14, 2018 at 05:38:31PM -0700, Jeykumar Sankaran wrote:
> On 2018-08-14 13:26, Sean Paul wrote:
> > On Tue, Aug 07, 2018 at 08:20:10PM -0700, Jeykumar Sankaran wrote:
> > > Subclass drm private state for DPU for handling driver
> > > specific data. Adds atomic private object and private
https://bugs.freedesktop.org/show_bug.cgi?id=107580
Kami changed:
What|Removed |Added
Hardware|Other |x86-64 (AMD64)
OS|All
https://bugs.freedesktop.org/show_bug.cgi?id=107509
Michel Dänzer changed:
What|Removed |Added
Assignee|mesa-dev@lists.freedesktop. |dri-devel@lists.freedesktop
https://bugs.freedesktop.org/show_bug.cgi?id=107493
--- Comment #4 from Michel Dänzer ---
(In reply to Sebastian Luncan from comment #0)
> When the drm driver is loaded on system boot or when is loaded manually the
> screen goes blank. The screen content reappears after the driver has been
> load
Since chromium.org is now enforcing DMARC, my mails are going to
people's spam folders. While this development might be desirable
for people I communicate with, it's undesirable for me :-)
Cc: Dave Airlie
Cc: Gustavo Padovan
Cc: Maarten Lankhorst
Signed-off-by: Sean Paul
---
MAINTAINERS | 2 +
https://bugs.freedesktop.org/show_bug.cgi?id=106529
--- Comment #3 from Mariusz Mazur ---
dc=1 codepath has the problem occur 100% of the times the display wakes up
(iirc).
dc=0 with your patch does not. It happens regularly, but not 100% of the times.
Which I guess does indicate there's some t
Em Sat, 11 Aug 2018 17:54:12 +0200
Arnd Bergmann escreveu:
> Building the DCN 1.0 Raven display driver with CONFIG_KCOV_INSTRUMENT_ALL=y
> and CONFIG_KCOV_ENABLE_COMPARISONS=y results in warnings about many functions
> that do a comparison of floating-point variables:
>
> drivers/gpu/drm/amd/dis
https://bugs.freedesktop.org/show_bug.cgi?id=107581
--- Comment #4 from Benjamin Hodgetts ---
Created attachment 141122
--> https://bugs.freedesktop.org/attachment.cgi?id=141122&action=edit
APITrace Playback Log
As it may contain something useful.
--
You are receiving this mail because:
You
Add kerneldoc description for "struct device_link *link"-member in
struct drm_panel.
Signed-off-by: Jyri Sarha
---
include/drm/drm_panel.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/drm/drm_panel.h b/include/drm/drm_panel.h
index 26a1b5f..c796251 100644
--- a/include/drm/drm_pan
https://bugs.freedesktop.org/show_bug.cgi?id=106529
--- Comment #4 from Alex Deucher ---
I suspect it may have something to do with the pulse timing from the monitor.
Long pulses are for connect/disconnect events and short pulses are a feedback
mechanism for the monitor to the driver. I suspect
On Wed, Aug 15, 2018 at 08:03:31PM +0300, Jyri Sarha wrote:
> Add kerneldoc description for "struct device_link *link"-member in
> struct drm_panel.
>
> Signed-off-by: Jyri Sarha
Reviewed-by: Daniel Vetter
> ---
> include/drm/drm_panel.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git
https://bugs.freedesktop.org/show_bug.cgi?id=107072
--- Comment #10 from Alex Deucher ---
(In reply to Pontus Gråskæg from comment #9)
> Looking at your dmesg output, it looks like you might have hit this
> bug/issue: bug 105880
>
> "[dc] No support for LVDS or VGA connectors (Cannot find any cr
https://bugs.freedesktop.org/show_bug.cgi?id=107072
--- Comment #11 from Alex Deucher ---
This is likely a duplicate of bug 106940.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.fre
https://bugs.freedesktop.org/show_bug.cgi?id=107072
--- Comment #12 from Alex Deucher ---
Does reverting f0c0761b38ac30b04d4fed436ff10e894ec0e525 help?
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
https://bugs.freedesktop.org/show_bug.cgi?id=107072
--- Comment #13 from Pontus Gråskæg ---
OK, I was misled by the errors in the dmesg log:
[ 14.186318] [drm:construct [amdgpu]] *ERROR* construct: Invalid Connector
ObjectID from Adapter Service for connector index:1! type 0 expected 3
[ 14.
https://bugs.freedesktop.org/show_bug.cgi?id=106940
Alex Deucher changed:
What|Removed |Added
Attachment #140198|text/x-log |text/plain
mime type|
https://bugs.freedesktop.org/show_bug.cgi?id=106940
--- Comment #28 from Alex Deucher ---
Created attachment 141123
--> https://bugs.freedesktop.org/attachment.cgi?id=141123&action=edit
patch to test
Does this patch fix the issue?
--
You are receiving this mail because:
You are the assignee
https://bugs.freedesktop.org/show_bug.cgi?id=107072
Alex Deucher changed:
What|Removed |Added
Attachment #140472|text/x-log |text/plain
mime type|
https://bugs.freedesktop.org/show_bug.cgi?id=107493
--- Comment #5 from Sebastian Luncan ---
(In reply to Michel Dänzer from comment #4)
> So this report is about the screen temporarily blanking while the driver
> initializes? If so, that's not really a bug, getting rid of that would be an
> enha
On Tue, Aug 07, 2018 at 08:20:11PM -0700, Jeykumar Sankaran wrote:
> Switch to state based resource management. This patch
> overhauls the resource manager and HW allocation methods by
> maintaining the global resource pool and allocated hw
> blocks in respective drm component states.
>
> Global r
Next version of https://patchwork.freedesktop.org/series/46815/
Same as previous version, but some small changes made to commit messages
and acks/rbs have been added
Lyude Paul (5):
drm/nouveau: Fix bogus drm_kms_helper_poll_enable() placement
drm/nouveau: Remove duplicate poll_enable() in pm
Currently, nouveau uses the generic drm_fb_helper_output_poll_changed()
function provided by DRM as it's output_poll_changed callback.
Unfortunately however, this function doesn't grab runtime PM references
early enough and even if it did-we can't block waiting for the device to
resume in output_po
Since actual hotplug notifications don't get disabled until
nouveau_display_fini() is called, all this will do is cause any hotplugs
that happen between this drm_kms_helper_poll_disable() call and the
actual hotplug disablement to potentially be dropped if ACPI isn't
around to help us.
Signed-off-
Turns out this part is my fault for not noticing when reviewing
9a2eba337cace ("drm/nouveau: Fix drm poll_helper handling"). Currently
we call drm_kms_helper_poll_enable() from nouveau_display_hpd_work().
This makes basically no sense however, because that means we're calling
drm_kms_helper_poll_en
It's true we can't resume the device from poll workers in
nouveau_connector_detect(). We can however, prevent the autosuspend
timer from elapsing immediately if it hasn't already without risking any
sort of deadlock with the runtime suspend/resume operations. So do that
instead of entirely avoiding
When we disable hotplugging on the GPU, we need to be able to
synchronize with each connector's hotplug interrupt handler before the
interrupt is finally disabled. This can be a problem however, since
nouveau_connector_detect() currently grabs a runtime power reference
when handling connector probi
https://bugs.freedesktop.org/show_bug.cgi?id=107580
--- Comment #1 from Andrey Grodzovsky ---
Can you provide a full dmesg log ?
>From the log you did provide it seems the device was during suspend operation.
Is it so ?
Does it happen only when you work with DRI_PRIME feature ? Can you run with
https://bugs.freedesktop.org/show_bug.cgi?id=93546
--- Comment #6 from MWATTT ---
This issue should be fixed on master.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
This doesn't do anything, drm_kms_helper_poll_enable() gets called in
nouveau_pmops_resume()->nouveau_display_resume()->nouveau_display_init()
already.
Signed-off-by: Lyude Paul
Reviewed-by: Karol Herbst
Acked-by: Daniel Vetter
Cc: Lukas Wunner
---
drivers/gpu/drm/nouveau/nouveau_vga.c | 1 -
This won't do anything but potentially make us miss hotplugs. We already
call drm_kms_helper_poll_disable() in
nouveau_pmops_suspend()->nouveau_display_suspend()->nouveau_display_fini()
Signed-off-by: Lyude Paul
Reviewed-by: Karol Herbst
Acked-by: Daniel Vetter
Cc: Lukas Wunner
---
drivers/gp
Next version of https://patchwork.freedesktop.org/series/48131/
Only changes are new A-Bs and R-Bs
Lyude Paul (3):
drm/nouveau: Remove useless poll_enable() call in
switcheroo_set_state()
drm/nouveau: Remove useless poll_disable() call in
switcheroo_set_state()
drm/nouveau: Remove u
Again, this doesn't do anything. drm_kms_helper_poll_enable() will have
already been called in nouveau_display_init()
Signed-off-by: Lyude Paul
Reviewed-by: Karol Herbst
Acked-by: Daniel Vetter
Cc: Lukas Wunner
---
drivers/gpu/drm/nouveau/nouveau_drm.c | 4 +---
1 file changed, 1 insertion(+)
From: Guenter Roeck
0day reports:
>> drivers/gpu/drm/bridge/ti-sn65dsi86.o: In function
`ti_sn_bridge_remove':
>> drivers/gpu/drm/bridge/ti-sn65dsi86.c:629: undefined reference to
`mipi_dsi_detach'
>> drivers/gpu/drm/bridge/ti-sn65dsi86.c:630: undefined reference to
`mipi_dsi_device_unregister'
https://bugs.freedesktop.org/show_bug.cgi?id=106940
--- Comment #29 from SET ---
The patch allows to view a normal booting.
However, the laptop hangs on suspend. Please see dmesg attachement. Switching
back to radeon.
--
You are receiving this mail because:
You are the assignee for the bug.___
https://bugs.freedesktop.org/show_bug.cgi?id=106940
--- Comment #30 from Server Angels ---
Actually rc8 from fedora/rawhide fixed it for me. I wasn't sure at first as the
initial upgrade didn't work, but a full power off / power off then did, which
was bizarre.
I did add the kernel option amdgpu
1 - 100 of 142 matches
Mail list logo
