https://bugs.freedesktop.org/show_bug.cgi?id=102553
--- Comment #21 from mercuriete ---
Patches already merged to linux master
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=16e205cf42da1f497b10a4a24f563e6c0d574eec
Please feel free to close this bug.
Thanks for f
https://bugs.freedesktop.org/show_bug.cgi?id=106040
--- Comment #1 from d...@gnunorth.ca ---
Created attachment 138832
--> https://bugs.freedesktop.org/attachment.cgi?id=138832&action=edit
dmesg on Vega 64
--
You are receiving this mail because:
You are the assignee for the bug.___
https://bugs.freedesktop.org/show_bug.cgi?id=106040
--- Comment #3 from d...@gnunorth.ca ---
Created attachment 138834
--> https://bugs.freedesktop.org/attachment.cgi?id=138834&action=edit
dmesg on RX 560 (dc off)
--
You are receiving this mail because:
You are the assignee for the bug.___
https://bugs.freedesktop.org/show_bug.cgi?id=106040
--- Comment #2 from d...@gnunorth.ca ---
Created attachment 138833
--> https://bugs.freedesktop.org/attachment.cgi?id=138833&action=edit
dmesg on RX 560 (dc on)
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=106040
Bug ID: 106040
Summary: [DC] HDMI Monitor has Overscan/Scaling
Product: DRI
Version: DRI git
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Severit
https://bugs.freedesktop.org/show_bug.cgi?id=101976
Pablo Estigarribia changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://bugs.freedesktop.org/show_bug.cgi?id=101976
--- Comment #13 from Pablo Estigarribia ---
(In reply to Marcelo "Marc" Ranolfi from comment #12)
> Kudos for your findings, Pablo Estigarribia.
>
> I made a workaround available in the form of setting DPM to "Low" on system
> start and calling
https://bugs.freedesktop.org/show_bug.cgi?id=101976
--- Comment #12 from Marcelo "Marc" Ranolfi ---
Kudos for your findings, Pablo Estigarribia.
I made a workaround available in the form of setting DPM to "Low" on system
start and calling a script when you need to set it to "High". They can be f
https://bugs.freedesktop.org/show_bug.cgi?id=105317
--- Comment #7 from Bráulio Barros de Oliveira ---
Likely duplicate of this https://bugs.freedesktop.org/show_bug.cgi?id=104817
--
You are receiving this mail because:
You are the assignee for the bug.__
https://bugs.freedesktop.org/show_bug.cgi?id=104817
--- Comment #4 from Bráulio Barros de Oliveira ---
Same here with AMD 2500U on a HP Envy x360, details at:
- https://bugzilla.redhat.com/show_bug.cgi?id=1562530
- https://lists.freedesktop.org/archives/amd-gfx/2018-March/020580.html
--
You are
On 2018-04-13 14:10, abhin...@codeaurora.org wrote:
Hi Sean
Thanks for the review.
Reply inline.
On 2018-04-13 13:26, Sean Paul wrote:
On Tue, Apr 10, 2018 at 06:54:06PM -0700, Abhinav Kumar wrote:
Make sure the video mode engine is on before waiting
for the video done interrupt.
Otherwise
Somehow I didn't manage to notice this the last time I looked at my
mmiotraces, these seem to be all valid registers.
Forwarding this to stable, as there's a small chance that not having
these could cause clockgating to be unstable.
Signed-off-by: Lyude Paul
Fixes: a0f79082bd174 ("drm/nouveau: A
There's an ongoing effort to remove VLAs[1] from the kernel to eventually
turn on -Wvla. Switch to a constant value that covers all hardware.
[1] https://lkml.org/lkml/2018/3/7/621
Reviewed-by: Felix Kuehling
Acked-by: Christian König
Signed-off-by: Laura Abbott
---
v3: Introduced a #define f
https://bugs.freedesktop.org/show_bug.cgi?id=106038
Bug ID: 106038
Summary: visual corruption and stuttery playback of VC-1
interlaced video with VAAPI and Polaris
Product: Mesa
Version: git
Hardware: x86-64 (AMD64)
On Tue, Apr 10, 2018 at 12:53:09PM +0200, Jacopo Mondi wrote:
> Document Thine THC63LVD1024 LVDS decoder device tree bindings.
>
> Signed-off-by: Jacopo Mondi
> Reviewed-by: Andrzej Hajda
> Reviewed-by: Niklas Söderlund
> Reviewed-by: Laurent Pinchart
> ---
> .../bindings/display/bridge/thine
Hi Sean
Thanks for the review.
Reply inline.
On 2018-04-13 13:26, Sean Paul wrote:
On Tue, Apr 10, 2018 at 06:54:06PM -0700, Abhinav Kumar wrote:
Make sure the video mode engine is on before waiting
for the video done interrupt.
Otherwise it leads to silent timeouts increasing display
turn O
Hi Sean
Thanks for the comments.
Some replies inline.
On 2018-04-13 13:46, Sean Paul wrote:
On Sat, Apr 07, 2018 at 12:06:53AM -0700, Abhinav Kumar wrote:
Register truly panel as a backlight led device and
provide methods to control its backlight operation.
Signed-off-by: Abhinav Kumar
---
On 2018-04-13 13:29, Sean Paul wrote:
On Tue, Apr 10, 2018 at 06:54:07PM -0700, Abhinav Kumar wrote:
Currently the DSI PHY timings are hard-coded for a specific panel
for the 10nm PHY.
Replace this with the auto PHY timing calculator which can calculate
the PHY timings for any panel.
Any chan
On Sat, Apr 07, 2018 at 12:06:53AM -0700, Abhinav Kumar wrote:
> Register truly panel as a backlight led device and
> provide methods to control its backlight operation.
>
> Signed-off-by: Abhinav Kumar
> ---
> drivers/gpu/drm/panel/panel-truly-dual-dsi.c | 96
> +++-
>
On Tue, Apr 10, 2018 at 06:54:07PM -0700, Abhinav Kumar wrote:
> Currently the DSI PHY timings are hard-coded for a specific panel
> for the 10nm PHY.
>
> Replace this with the auto PHY timing calculator which can calculate
> the PHY timings for any panel.
Any chance you could document what you'r
On Tue, Apr 10, 2018 at 06:54:06PM -0700, Abhinav Kumar wrote:
> Make sure the video mode engine is on before waiting
> for the video done interrupt.
>
> Otherwise it leads to silent timeouts increasing display
> turn ON time.
>
> Changes in v2:
> - Replace pr_err with dev_err
> - Changed error m
Hi, Daniel,
On 04/13/2018 07:13 PM, Daniel Vetter wrote:
Hi Thomas,
On Wed, Apr 11, 2018 at 10:27:06AM +0200, Thomas Hellstrom wrote:
Hi!
Thinking of adding ww-mutexes for reservation also of vmwgfx resources,
(like surfaces), I became a bit worried that doubling the locks taken during
comman
On Tue, Apr 10, 2018 at 06:16:08PM -0700, Chandan Uddaraju wrote:
> Current DSI driver uses two connectors for dual DSI case even
> though we only have one panel. Fix this by implementing one
> connector/bridge for dual DSI use case. Use master DSI
> controllers to register one connector/bridge.
>
On Tue, Apr 10, 2018 at 06:16:07PM -0700, Chandan Uddaraju wrote:
> For dual dsi mode, the horizontal timing needs
> to be divided by half since both the dsi controllers
> will be driving this panel. Adjust the pixel clock and
> DSI timing accordingly.
>
> Change-Id: Iee1226b2eef9eea23d9653e3d738e
https://bugs.freedesktop.org/show_bug.cgi?id=105880
--- Comment #16 from Chí-Thanh Christopher Nguyễn ---
I tried with 4.16, made no difference. But as dc_log=1 on 4.16 gives no helpful
additional output, I will try on Monday with 4.15 again. It may also be
possible that I am affected both by the
On 2018-04-13 06:00 AM, Daniel Vetter wrote:
> This tries to align with the X.org communities's long-standing
> tradition of trying to be an inclusive community and handing out
> commit rights fairly freely.
>
> We also tend to not revoke commit rights for people no longer
> regularly active in a
https://bugs.freedesktop.org/show_bug.cgi?id=105425
--- Comment #29 from MirceaKitsune ---
For the first time ever, I might finally have some very good news on this
issue! It will take several more days to confirm, then possibly another month
to pinpoint the exact option responsible. However it's
On Fri, Apr 13, 2018 at 10:53:00AM +0530, Sandeep Panda wrote:
> Add support for TI's sn65dsi86 dsi2edp bridge chip.
> The chip converts DSI transmitted signal to eDP signal,
> which is fed to the connected eDP panel.
>
> This chip can be controlled via either i2c interface or
> dsi interface. Cur
On 2018-04-12 05:38 PM, Stéphane Marchesin wrote:
> On Tue, Apr 10, 2018 at 12:37 AM, Michel Dänzer wrote:
>> On 2018-04-10 08:45 AM, Christian König wrote:
>>> Am 09.04.2018 um 23:45 schrieb Manasi Navare:
Thanks for initiating the discussion. Find my comments below:
On Mon, Apr 09, 201
On 2018-04-13 12:04 PM, Daniel Vetter wrote:
> On Mon, Apr 09, 2018 at 04:00:21PM -0400, Harry Wentland wrote:
>> Adding dri-devel, which I should've included from the start.
>
> Top posting, because I'm lazy and was out sick ...
>
> Few observations:
> - Stéphane has a great point which seems to
https://bugs.freedesktop.org/show_bug.cgi?id=105880
--- Comment #15 from David Henningsson ---
(In reply to Michel Dänzer from comment #10)
> (In reply to David Henningsson from comment #8)
> > The regression is between 4.15rc2 and 4.15rc3
>
> Any chance you can bisect between these two?
I can,
On Fri, Apr 13, 2018 at 1:23 AM Sandeep Panda wrote:
> Document the bindings used for the sn65dsi86 DSI to eDP bridge.
> Signed-off-by: Sandeep Panda
> ---
> .../bindings/display/bridge/ti,sn65dsi86.txt | 75
++
> 1 file changed, 75 insertions(+)
> create mode 100
https://bugzilla.kernel.org/show_bug.cgi?id=199101
--- Comment #18 from Martin Babutzka (martin.babut...@web.de) ---
Okay the AMD devs reverted the corresponding commit in amd-staging-drm-next
(https://cgit.freedesktop.org/~agd5f/linux/commit/?h=amd-staging-drm-next&id=fc0644eddd2d5f77aac44ad2ab5a
On Tue, Apr 10, 2018 at 07:19:26AM +0200, Philippe Cornu wrote:
> Add the 3 optional power supplies using the exact description
> found in the document named
> "SiI9022A/SiI9024A HDMI Transmitter Data Sheet (August 2016)".
>
> Signed-off-by: Philippe Cornu
> ---
> Documentation/devicetree/bindin
On Mon, Apr 09, 2018 at 04:00:38PM -0700, Eric Anholt wrote:
> The GPU subsystem node was a workaround to have a central device to
> bind V3D and display to. Following the lead of 246774d17fc0
> ("drm/etnaviv: remove the need for a gpu-subsystem DT node"), remove
> the subsystem node usage and jus
On Mon, Apr 09, 2018 at 12:59:15PM +0200, Peter Rosin wrote:
> Useful for beating cases where an output mode selection heuristic
> fails.
>
> Signed-off-by: Peter Rosin
> ---
> Documentation/devicetree/bindings/display/atmel/hlcdc-dc.txt | 4
> 1 file changed, 4 insertions(+)
>
> diff --gi
On Mon, Apr 09, 2018 at 12:59:14PM +0200, Peter Rosin wrote:
> Start list of actual chips compatible with "lvds-encoder".
>
> Reviewed-by: Laurent Pinchart
> Signed-off-by: Peter Rosin
> ---
> .../devicetree/bindings/display/bridge/lvds-transmitter.txt | 8
> +++-
> 1 file changed, 7
Hi Thomas,
On Wed, Apr 11, 2018 at 10:27:06AM +0200, Thomas Hellstrom wrote:
> Hi!
>
> Thinking of adding ww-mutexes for reservation also of vmwgfx resources,
> (like surfaces), I became a bit worried that doubling the locks taken during
> command submission wouldn't be a good thing. Particularly
Hi Noralf,
1 comment inline.
On 13-04-18 18:53, Noralf Trønnes wrote:
Getting rotation info is cheap so we can do it on demand.
This is done in preparation for the removal of struct drm_fb_helper_crtc.
Cc: Hans de Goede
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/drm_fb_helper.c | 1
Argh, it didn't go through this time either.
I'll just have to strip off recipients and just send to the lists when
the cool off period is over.
Sorry about the noise, I'll have to investigate this further.
Noralf.
Den 13.04.2018 18.53, skrev Noralf Trønnes:
This patchset explores the possi
These helpers keep track of fbdev users and drm_driver.last_close will
only restore fbdev when actually in use. Additionally the display is
turned off when the last user is closing. fbcon is a user in this context.
If struct fb_ops is defined in a library, fb_open() takes a ref on the
library (fb_
The stage is now set for a clean removal of drm_fb_helper_crtc.
struct drm_client_display is doing its job now.
Also remove the drm_fb_helper_funcs->initial_config which has been
superseded by drm_driver->initial_client_display.
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/drm_fb_helper.c
If there's a DRM master, return -EBUSY.
Block userspace from becoming master by taking the master lock while
the client is setting the mode.
Suggested-by: Daniel Vetter
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/drm_auth.c | 33 +
drivers/gpu/drm/drm_
No need to maintain a list of registered connectors. Just use the
connector iterator.
TODO: Remove:
- drm_fb_helper_add_one_connector()
- drm_fb_helper_single_add_all_connectors()
- drm_fb_helper_remove_one_connector()
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/drm_fb_helper.c | 359
Call the function drm_client_find_display().
No functional change apart from making width/height arguments optional.
Some function name/signature changes and whitespace adjustments.
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/drm_client.c| 399
Make ioctl wrappers for functions that will be used by the in-kernel API.
The following functions are touched:
- drm_mode_create_dumb_ioctl()
- drm_mode_destroy_dumb_ioctl()
- drm_mode_addfb2()
- drm_mode_rmfb()
- drm_prime_handle_to_fd_ioctl()
drm_mode_addfb2() also gets the ability to override t
Give clients easy access to the display modes.
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/drm_client.c | 159 +--
include/drm/drm_client.h | 25 +++
2 files changed, 148 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/drm_clien
Avoid pinning the module when exporting a GEM object as a dmabuf. This
makes it possible to unload drivers that has in-kernel clients using it.
The client is removed on drm_dev_unregister() so no need to pin the driver.
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/drm_prime.c | 24 +
The modesetting code is already present, this adds the rest of the API.
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/drm_client.c | 573 +
drivers/gpu/drm/drm_debugfs.c | 7 +
drivers/gpu/drm/drm_drv.c | 11 +
drivers/gpu/drm/drm_fi
As part of moving the modesetting code out of drm_fb_helper and into
drm_client, the drm_fb_helper_funcs->initial_config callback needs to go.
Replace it with a drm_driver->initial_client_display callback that can
work for all in-kernel clients.
TODO:
- Add a patch that moves the function out of i
Add functions to deal with the registred connectors as an array:
- drm_connector_get_all()
- drm_connector_put_all()
And to get the enabled status of those connectors:
drm_connector_get_enabled_status()
This is prep work to remove struct drm_fb_helper_connector.
Signed-off-by: Noralf Trønnes
--
Move them over from drm_fb_helper since they are connector functions.
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/drm_connector.c| 94 ++
drivers/gpu/drm/drm_fb_helper.c| 75 ++
drivers/gpu/drm/i915/intel_fbdev.c | 7
This moves the committing part of the modesetting code to drm_client.
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/drm_client.c| 242
drivers/gpu/drm/drm_fb_helper.c | 216 +--
include/drm/drm_client.h| 8
Prepare for moving drm_fb_helper modesetting code to drm_client.
drm_client will be linked to drm.ko, so move
__drm_atomic_helper_disable_plane() and __drm_atomic_helper_set_config()
out of drm_kms_helper.ko.
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/drm_atomic.c| 168 +++
Atomic drivers can't use them so finish what was started in
commit 9c79e0b1d096 ("drm/fb-helper: Give up on kgdb for atomic drivers").
This prepares the ground for creating modesets on demand.
TODO:
- Actually remove the functions, not just the contents.
- Nuke drm_crtc_helper_funcs->mode_set_bas
Getting rotation info is cheap so we can do it on demand.
This is done in preparation for the removal of struct drm_fb_helper_crtc.
Cc: Hans de Goede
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/drm_fb_helper.c | 131
include/drm/drm_fb_helper.h
Prepare to move the modeset committing code to drm_client.
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/drm_fb_helper.c | 161
include/drm/drm_fb_helper.h | 8 ++
2 files changed, 89 insertions(+), 80 deletions(-)
diff --git a/drivers/gpu/drm/
This the beginning of an API for in-kernel clients.
First out is a display representation that will be used by drm_fb_helper
in order to move out its mode setting code.
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/Makefile | 2 +-
drivers/gpu/drm/drm_client.c | 119 +++
For each enabled crtc the functions sets dpms on all registered connectors.
Limit this to only doing it once and on the connectors actually in use.
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/drm_fb_helper.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/dr
It only makes sense for userspace clients.
Signed-off-by: Noralf Trønnes
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/drm_file.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
index d4588d33f91c..5
From: David Herrmann
Rather than doing drm_file allocation/destruction right in the fops, lets
provide separate helpers. This decouples drm_file management from the
still-mandatory drm-fops. It prepares for use of drm_file without the
fops, both by possible separate fops implementations and APIs
This patchset explores the possibility of having generic fbdev emulation
in DRM for drivers that supports dumb buffers which they can export. An
API is added to support in-kernel clients in general.
In this version I was able to reuse the modesetting code from
drm_fb_helper in the client API. This
https://bugzilla.kernel.org/show_bug.cgi?id=199385
Alex Deucher (alexdeuc...@gmail.com) changed:
What|Removed |Added
CC||alexdeuc...@gmail.c
https://bugs.freedesktop.org/show_bug.cgi?id=105880
--- Comment #14 from Alex Deucher ---
Please try attachment 138813 on bug 105996.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.f
Hello,
small self review, as I've just noticed a trivial error.
On Tue, Apr 10, 2018 at 12:53:10PM +0200, Jacopo Mondi wrote:
> Add DRM bridge driver for Thine THC63LVD1024 LVDS to digital parallel
> output converter.
>
> Signed-off-by: Jacopo Mondi
> Reviewed-by: Andrzej Hajda
> Reviewed-by:
On Fri, Apr 13, 2018 at 06:08:24PM +0200, Daniel Vetter wrote:
> On Wed, Apr 11, 2018 at 09:32:16AM +0200, Simon Horman wrote:
> > On Tue, Apr 10, 2018 at 02:32:40PM +0200, Wolfram Sang wrote:
> > > The documentation was wrong, gpiod_get_direction() returns 0/1 instead
> > > of the GPIOF_* flags. T
Commit 51f7415039d4 ("drm/amd/amdgpu: creating two I2S instances for
stoney/cz") added support for the "BT_I2S" ACP i2s channel. As part of
this change, one additional acp resource was added, but the "num_resource"
count was accidentally incremented by 2.
This incorrect count eventually causes mf
On Wed, Apr 11, 2018 at 09:32:16AM +0200, Simon Horman wrote:
> On Tue, Apr 10, 2018 at 02:32:40PM +0200, Wolfram Sang wrote:
> > The documentation was wrong, gpiod_get_direction() returns 0/1 instead
> > of the GPIOF_* flags. The docs were fixed with commit 94fc73094abe47
> > ("gpio: correct docs
On Mon, Apr 09, 2018 at 04:00:21PM -0400, Harry Wentland wrote:
> Adding dri-devel, which I should've included from the start.
Top posting, because I'm lazy and was out sick ...
Few observations:
- Stéphane has a great point which seems to have been ignored thus far.
- Where's the VK extension fo
Hi Daniel,
On Fri, Apr 13, 2018 at 05:44:09PM +0200, Daniel Vetter wrote:
On Mon, Apr 09, 2018 at 05:15:08PM +0100, Brian Starkey wrote:
Hi Daniel,
On Mon, Apr 09, 2018 at 10:23:37AM +0200, Daniel Vetter wrote:
> On Fri, Apr 06, 2018 at 08:02:16PM +0100, Ayan Halder wrote:
> > On Tue, Mar 27,
On Mon, Apr 09, 2018 at 12:43:07PM +0300, Laurent Pinchart wrote:
> Hi Daniel,
>
> On Monday, 9 April 2018 12:18:28 EEST Daniel Vetter wrote:
> > On Mon, Apr 09, 2018 at 11:56:55AM +0300, Laurent Pinchart wrote:
> > > On Monday, 9 April 2018 11:53:07 EEST Daniel Vetter wrote:
> > >> On Fri, Apr 06
On Mon, Apr 09, 2018 at 09:45:51AM +, Alexey Brodkin wrote:
> Hi Daniel,
>
> On Mon, 2018-04-09 at 11:17 +0200, Daniel Vetter wrote:
> > On Mon, Apr 09, 2018 at 08:55:36AM +, Alexey Brodkin wrote:
> > > Hi Daniel,
> > >
> > > On Mon, 2018-04-09 at 10:31 +0200, Daniel Vetter wrote:
> > > >
On Wed, Apr 11, 2018 at 01:57:15PM +0530, Ramalingam C wrote:
>
>
> On Monday 09 April 2018 01:58 PM, Daniel Vetter wrote:
> > On Fri, Apr 06, 2018 at 07:02:02PM +0300, Ville Syrjälä wrote:
> > > On Mon, Apr 02, 2018 at 02:35:42PM +0530, Ramalingam C wrote:
> > > >
> > > > On Thursday 29 March 2
On Mon, Apr 09, 2018 at 12:25:57PM +0100, Emil Velikov wrote:
> On 9 April 2018 at 11:24, Emil Velikov wrote:
> > On 9 April 2018 at 09:26, Daniel Vetter wrote:
> >
> >>> - point drm_device::dev to the parent of the virtio_device
> >>> The biggest hack imaginable, if even possible.
> >>
> >> Wha
On Mon, Apr 09, 2018 at 05:15:08PM +0100, Brian Starkey wrote:
> Hi Daniel,
>
> On Mon, Apr 09, 2018 at 10:23:37AM +0200, Daniel Vetter wrote:
> > On Fri, Apr 06, 2018 at 08:02:16PM +0100, Ayan Halder wrote:
> > > On Tue, Mar 27, 2018 at 01:09:36PM +0200, Daniel Vetter wrote:
> > > > On Tue, Mar 2
On Wed, Apr 11, 2018 at 08:59:32AM +0300, Oleksandr Andrushchenko wrote:
> On 04/10/2018 08:26 PM, Dongwon Kim wrote:
> > On Tue, Apr 10, 2018 at 09:37:53AM +0300, Oleksandr Andrushchenko wrote:
> > > On 04/06/2018 09:57 PM, Dongwon Kim wrote:
> > > > On Fri, Apr 06, 2018 at 03:36:03PM +0300, Oleks
One needs to ensure that the crtcs are shutdown so that the
drm_crtc_state->connector_mask reflects that no connectors
are currently active. Further, it reduces the reference
count for each connector. This ensures that the connectors
and encoders can be cleanly removed either when _unbind
is called
https://bugs.freedesktop.org/show_bug.cgi?id=104391
--- Comment #6 from Andy Furniss ---
It seems that
HDMI has no sound after Panel power off/on
is the cause of the warnings.
I tested 4.18-wip, no sound of course but nothing in dmesg.
I then applied "HDMI has no sound after Panel power off/o
dma_unmap_sg() should be called with the same number of entries
originally passed to dma_map_sg(), not the number it returned, which may
be fewer. Admittedly this driver probably never runs on non-coherent
architectures where getting that wrong could lead to data loss, but it's
always good to be co
On Fri, Apr 13, 2018 at 4:46 PM, Thomas Huth wrote:
> On 13.04.2018 16:32, Daniel Vetter wrote:
>> On Fri, Apr 13, 2018 at 11:40 AM, Thomas Huth wrote:
>>> By enabling the DRM code for virtio-gpu on S390, you currently also get
>>> all the code that is enabled by CONFIG_HDMI and CONFIG_I2C automa
On 13.04.2018 16:32, Daniel Vetter wrote:
> On Fri, Apr 13, 2018 at 11:40 AM, Thomas Huth wrote:
>> By enabling the DRM code for virtio-gpu on S390, you currently also get
>> all the code that is enabled by CONFIG_HDMI and CONFIG_I2C automatically.
>> This is quite ugly, since on S390, there is no
On Fri, Apr 13, 2018 at 11:40 AM, Thomas Huth wrote:
> By enabling the DRM code for virtio-gpu on S390, you currently also get
> all the code that is enabled by CONFIG_HDMI and CONFIG_I2C automatically.
> This is quite ugly, since on S390, there is no HDMI and no I2C. Thus it
> would be great if t
On Tue, Apr 10, 2018 at 03:00:01PM +0200, Boris Brezillon wrote:
> From: Boris Brezillon
>
> Document the bindings used for the Cadence DSI bridge.
>
> Signed-off-by: Boris Brezillon
> ---
> Hello Rob,
>
> I dropped your Acked-by because this version now documents the DPHY
> bindings.
>
> Reg
https://bugs.freedesktop.org/show_bug.cgi?id=105945
--- Comment #1 from Timothy Arceri ---
I tried this game yesterday but it crashed entering the tutorial. Today I tried
again and it applied an update (no more crashing). The trees etc are displayed
fine for me using radeonsi git. But there are s
On Fri, 13 Apr 2018, Thomas Huth wrote:
> Selecting CONFIG_HDMI for S390 is inappropriate - there is no real
> graphic hardware on this architecture. The drm subsystem is only
> enabled here for using the virtual graphics card "virtio-gpu". So
> it should be possible to compile the drm subsystem a
On second thought, I pushed this patchset here:
https://github.com/ARM-software/drm-hwcomposer/tree/scene_flattening_support
On Fri, Apr 13, 2018 at 10:52:55AM +0100, Alexandru-Cosmin Gheorghe wrote:
> Hi John,
>
> On Thu, Apr 12, 2018 at 04:18:54PM -0700, John Stultz wrote:
> > On Wed, Apr 11, 2
https://bugs.freedesktop.org/show_bug.cgi?id=105880
Chí-Thanh Christopher Nguyễn changed:
What|Removed |Added
Summary|[dc][kabini] Cannot find|[dc] No support for LVDS
On Fri, Apr 13, 2018 at 05:30:04PM +0530, Jagan Teki wrote:
> On Wed, Apr 11, 2018 at 6:13 PM, Maxime Ripard
> wrote:
> > On Wed, Apr 04, 2018 at 11:57:08AM +0200, Maxime Ripard wrote:
> >> Hi,
> >>
> >> Here is an preliminary version of the MIPI-DSI support for the Allwinner
> >> SoCs.
> >>
> >>
https://bugs.freedesktop.org/show_bug.cgi?id=105880
--- Comment #12 from Chí-Thanh Christopher Nguyễn ---
So, with the additional dmesg output from kernel 4.15, the following appeared
interesting:
[ 43.356569] [drm] DC: create_links: connectors_num: physical:3, virtual:0
[ 43.356583] [drm] U
https://bugs.freedesktop.org/show_bug.cgi?id=105880
--- Comment #11 from Chí-Thanh Christopher Nguyễn ---
Created attachment 138824
--> https://bugs.freedesktop.org/attachment.cgi?id=138824&action=edit
dmesg from kernel 4.15 with cik_support=1 dc=1 dc_log=1
Going back to kernel 4.15 makes no d
https://bugs.freedesktop.org/show_bug.cgi?id=42128
Timothy Arceri changed:
What|Removed |Added
Component|Mesa core |Drivers/DRI/i915
Assignee|mes
https://bugs.freedesktop.org/show_bug.cgi?id=70402
Timothy Arceri changed:
What|Removed |Added
Assignee|mesa-dev@lists.freedesktop. |dri-devel@lists.freedesktop
https://bugs.freedesktop.org/show_bug.cgi?id=64091
Timothy Arceri changed:
What|Removed |Added
Component|Mesa core |Drivers/Gallium/r600
Assignee
https://bugs.freedesktop.org/show_bug.cgi?id=96519
Timothy Arceri changed:
What|Removed |Added
Component|Mesa core |Drivers/Gallium/r300
Assignee
https://bugzilla.kernel.org/show_bug.cgi?id=199357
Mathias Tillman (master.ho...@gmail.com) changed:
What|Removed |Added
Status|NEW |RESOLVED
Hi Inki,
On 13 April 2018 at 10:55, Inki Dae wrote:
> 2018년 03월 30일 23:11에 Daniel Stone 이(가) 쓴 글:
>> Since drm_framebuffer can now store GEM objects directly, place them
>> there rather than in our own subclass. As this makes the framebuffer
>> create_handle and destroy functions the same as the
This tries to align with the X.org communities's long-standing
tradition of trying to be an inclusive community and handing out
commit rights fairly freely.
We also tend to not revoke commit rights for people no longer
regularly active in a given project, as long as they're still part of
the large
Hi John,
On Thu, Apr 12, 2018 at 04:18:54PM -0700, John Stultz wrote:
> On Wed, Apr 11, 2018 at 8:22 AM, Alexandru Gheorghe
> wrote:
> > Flattening a scene in order to reduce memory consumption it's an idea
> > which had been floating around on irc and mailing list several times,
> > this patchse
Selecting CONFIG_HDMI for S390 is inappropriate - there is no real
graphic hardware on this architecture. The drm subsystem is only
enabled here for using the virtual graphics card "virtio-gpu". So
it should be possible to compile the drm subsystem also without
CONFIG_I2C. Tweak the Makefile to onl
Selecting CONFIG_HDMI for S390 is inappropriate - there is no real
graphic hardware on this architecture. The drm subsystem is only
enabled here for using the virtual graphics card "virtio-gpu". So
it should be possible to compile the drm subsystem also without
CONFIG_DRM. Let's move the related co
1 - 100 of 112 matches
Mail list logo
