Hi Souptick,
On Friday, 28 September 2018 23:02:32 EEST Souptick Joarder wrote:
> On 28-Sep-2018 9:00 PM, "Laurent Pinchart" wrote:
> > On Friday, 28 September 2018 18:05:18 EEST Laurent Pinchart wrote:
> >> On Thursday, 27 September 2018 09:34:18 EEST Souptick Joarder wrote:
> >>> On Tue, Sep 18,
https://bugzilla.kernel.org/show_bug.cgi?id=201275
--- Comment #6 from quirin.blae...@freenet.de ---
RX560 is Polaris11, so Bug may be ported from Polaris20
--
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel
https://bugzilla.kernel.org/show_bug.cgi?id=201275
--- Comment #5 from quirin.blae...@freenet.de ---
Created attachment 278841
--> https://bugzilla.kernel.org/attachment.cgi?id=278841&action=edit
bisect result
Includes bisect steps + sensors output
--
You are receiving this mail because:
You
https://bugs.freedesktop.org/show_bug.cgi?id=107261
--- Comment #7 from Ian ---
I've noticed that I can deterministically create these error messages upon
locking my screen and thus allowing my monitor to go into power-save mode.
Sometimes, my resolution also goes to 1024×768 on wake, which is i
https://bugzilla.kernel.org/show_bug.cgi?id=201285
--- Comment #1 from Philip Armstrong (p...@kantaka.co.uk) ---
Forgot to mention: amdgpu firmware is latest from linux-firmware git.
--
You are receiving this mail because:
You are watching the assignee of the bug.
___
https://bugzilla.kernel.org/show_bug.cgi?id=201285
Bug ID: 201285
Summary: Kernel oops in amdgpu with Ryzen5 2400G
Product: Drivers
Version: 2.5
Kernel Version: 4.19-rc5
Hardware: Intel
OS: Linux
Tree: Mainlin
https://bugs.freedesktop.org/show_bug.cgi?id=108100
Jure Repinc changed:
What|Removed |Added
Summary|RX480: HDMI display |RX480: HDMI display
|un
https://bugs.freedesktop.org/show_bug.cgi?id=108100
--- Comment #3 from Jure Repinc ---
Created attachment 141799
--> https://bugs.freedesktop.org/attachment.cgi?id=141799&action=edit
dmidecode
--
You are receiving this mail because:
You are the assignee for the bug.__
https://bugs.freedesktop.org/show_bug.cgi?id=108100
--- Comment #2 from Jure Repinc ---
Created attachment 141798
--> https://bugs.freedesktop.org/attachment.cgi?id=141798&action=edit
lspci
--
You are receiving this mail because:
You are the assignee for the bug.__
https://bugs.freedesktop.org/show_bug.cgi?id=108100
Bug ID: 108100
Summary: RX480: HDMI display unavailable with amdgpu.dc=1, boot
error
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resou
rce.c:1721
P
https://bugs.freedesktop.org/show_bug.cgi?id=108100
--- Comment #1 from Jure Repinc ---
Created attachment 141797
--> https://bugs.freedesktop.org/attachment.cgi?id=141797&action=edit
dmesg-4.17.14
--
You are receiving this mail because:
You are the assignee for the bug.__
https://bugzilla.kernel.org/show_bug.cgi?id=200621
--- Comment #27 from Jon (jon...@gmail.com) ---
After upgrading to 4.18.8 it certainly seems more stable. Normally an uptime
of about two to three days was the best I could hope for. Current uptime is
just shy of six days.
--
You are receiving
https://bugs.freedesktop.org/show_bug.cgi?id=108099
Bug ID: 108099
Summary: clinfo report an llvm error
Product: DRI
Version: XOrg git
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Severity: normal
Den 28.09.2018 23.01, skrev Stefan Wahren:
Hi,
Sergey Suloev already reported this NULL pointer dereference [1]. Now he was
able to provide a Kernel config and i'm able to reproduce it with a Raspberry
Pi 3 (arm64) and Linux 4.19-rc5. It seems like a invalid config [2] for vc4,
but neverthel
Sergey Suloev reported a crash happening in drm_client_dev_hotplug()
when fbdev had failed to register.
[9.124598] vc4_hdmi 3f902000.hdmi: ASoC: Failed to create component debugfs
directory
[9.147667] vc4_hdmi 3f902000.hdmi: vc4-hdmi-hifi <-> 3f902000.hdmi mapping
ok
[9.155184] vc4_h
https://bugs.freedesktop.org/show_bug.cgi?id=108098
Bug ID: 108098
Summary: Acer Swift 3 Ryzen 7 2700U, amdgpu, graphics freezes
on 4.15.0-34
Product: DRI
Version: unspecified
Hardware: x86-64 (AMD64)
OS: Li
On Thu, Sep 27, 2018 at 11:03:19PM +0530, Jagan Teki wrote:
> On Thu, Sep 27, 2018 at 10:44 PM Maxime Ripard
> wrote:
> >
> > On Thu, Sep 27, 2018 at 05:18:46PM +0530, Jagan Teki wrote:
> > > Accordingly to BPI-M64-bsp DE DSI code Video start delay
> > > can be computed by subtracting total vertic
On Thu, Sep 27, 2018 at 09:50:34PM +0530, Jagan Teki wrote:
> On Thu, Sep 27, 2018 at 8:51 PM Maxime Ripard
> wrote:
> >
> > On Thu, Sep 27, 2018 at 05:18:44PM +0530, Jagan Teki wrote:
> > > According to horizontal and vertical timings are defined
> > > per the diagram from include/drm/drm_modes.
On Thu, Sep 27, 2018 at 11:06:50PM +0530, Jagan Teki wrote:
> >
> > > ret = sun6i_dsi_dcs_write_short(dsi, msg);
> > > @@ -885,6 +886,8 @@ static ssize_t sun6i_dsi_transfer(struct
> > > mipi_dsi_host *host,
> > > }
> > >
> > > default:
> > > + dev_err(
On Sat, Sep 29, 2018 at 02:23:37PM +0200, Hans de Goede wrote:
> Hi,
>
> On 28-09-18 14:38, Greg Kroah-Hartman wrote:
> > On Wed, Sep 26, 2018 at 09:41:52PM +0200, Hans de Goede wrote:
> > > This cleanups 2 things:
> > >
> > > 1) The first time we loop over the crtc-s, to compare framebuffers, fb
Hi,
On 28-09-18 14:38, Greg Kroah-Hartman wrote:
On Wed, Sep 26, 2018 at 09:41:52PM +0200, Hans de Goede wrote:
This cleanups 2 things:
1) The first time we loop over the crtc-s, to compare framebuffers, fb1 may
get set to NULL by the fb1 = CRTC_FB(crtci); statement and then we call
to_vbox_fr
Replace vbox_crtc_commit and vbox_crtc_disable with
vbox_crtc_atomic_[en|dis]able which are the preferred callbacks for
these for atomic drivers.
Signed-off-by: Hans de Goede
---
drivers/staging/vboxvideo/vbox_mode.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/
Wire up state object handlers for the crtc-s and the planes, call
drm_mode_config_reset() after creating all the crtc-s and encoders and
remove the legacy drm_helper_disable_unused_functions() call.
Signed-off-by: Hans de Goede
---
drivers/staging/vboxvideo/vbox_fb.c | 3 ---
drivers/staging/
Store fbhelper and afb struct directly in vbox_private and use
drm_fb_helper_fbdev_setup to replace vbox_fbdev_init, note we cannot use
drm_fb_helper_fbdev_teardown since we use a private framebuffer for the
fbdev.
And replace vbox_driver_lastclose with drm_fb_helper_lastclose.
Signed-off-by: Han
This cleanups 2 things:
1) The first time we loop over the crtc-s, to compare framebuffers, fb1 may
get set to NULL by the fb1 = CRTC_FB(crtci); statement and then we call
to_vbox_framebuffer() on it. The result of this call is only used for
an address comparison, so we don't end up dereferencing
drm_mode_page_flip_ioctl() cannot deal with the in between phase of
the transitioning to atomic modeset support. Once we start using
drm_helper_crtc_mode_set(), we start setting plane->state on the primary
plane. But we are not fully atomic yet so then set both plane-state->fb
and plane->fb.
If bo
Extend our planes atomic_check callbacks to be more thorough by calling
the drm_atomic_helper_check_plane_state helper.
Signed-off-by: Hans de Goede
---
drivers/staging/vboxvideo/vbox_mode.c | 30 ++-
1 file changed, 29 insertions(+), 1 deletion(-)
diff --git a/drivers/s
When setting a mode we not only pass the mode to the hypervisor,
but also information on how to map / translate input coordinates
for the emulated USB tablet. This input-mapping may change when
the mode on *another* crtc changes.
This means that sometimes we must do a modeset on other crtc-s then
Once we are fully atomic plane->fb will always be NULL and we also
should not access things like crtc->enabled and crt->[hw]mode.
Now that we've wired up the state object handlers, we always have a
plane_state and crtc_state so change the code referencing plane->fb and
crtc->* to use the data from
Atomic modesetting does not use the traditional dpms call backs, instead
we should check crtc_state->active.
Signed-off-by: Hans de Goede
---
drivers/staging/vboxvideo/vbox_drv.h | 1 -
drivers/staging/vboxvideo/vbox_mode.c | 28 ++-
2 files changed, 2 insertions(+), 27
Use drm_plane_helpers for the primary plane and replace our custom
mode_set callback with drm_helper_crtc_mode_set.
Signed-off-by: Hans de Goede
---
drivers/staging/vboxvideo/vbox_mode.c | 116 --
1 file changed, 90 insertions(+), 26 deletions(-)
diff --git a/drivers/sta
Now that the state objects are wired up, we can:
1) Move to the final atomic handlers
2) Wire up atomic set_config helper
3) Switch to drm_mode_config_helper_suspend/resume for suspend/resume
4) Enable atomic modesetting ioctl
This is all done in one commit because doing this piecemeal leads to
a
In preparation for atomic conversion, let's use the transitional atomic
helpers drm_plane_helper_update/disable.
Signed-off-by: Hans de Goede
---
drivers/staging/vboxvideo/vbox_drv.h | 5 -
drivers/staging/vboxvideo/vbox_mode.c | 386 +-
2 files changed, 186 insertions
Restore page-flip support now that the atomic conversion is complete.
Since the mode parameter to vbox_crtc_set_base_and_mode() now never
is NULL call drm_atomic_crtc_needs_modeset() to check if we need to
check for input-mapping changes, to avoid doing unnecesarry work on
a flip. And hookup the d
vbox_mode_valid always returns MODE_OK, which is also the default if no
mode_valid callback is defined.
vbox_best_single_encoder chains to drm_encoder_find, the drm-core will
call drm_encoder_find itself if there is no best_encoder call back.
Signed-off-by: Hans de Goede
---
drivers/staging/vbo
Hi All,
This series converts the vboxvideo driver to the modesetting API, once this
is merged I will submit a patch to move the driver out of staging and into
drivers/gpu/drm.
This series consists of 3 parts:
1) More cleanups / prep work for atomic conversion
2) The actual atomic conversion, thi
All the encoder_helper_funcs are optional, and even setting the
drm_encoder_helper_funcs vtable itself is optional and may be left out
when not using any of the helper funcs, so lets drop all of this.
Signed-off-by: Hans de Goede
---
drivers/staging/vboxvideo/vbox_mode.c | 34 ---
From: Colin Ian King
Trivial fix to spelling mistake in pr_err message
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
b/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
inde
Hello Dirk,
I think Christian is talking about this branch:
https://cgit.freedesktop.org/~deathsimple/linux/log/?h=p2p
His 'home' is, here:
https://cgit.freedesktop.org/~deathsimple/linux/
Happy hacking! ;-)
Dieter
Am 29.09.2018 10:17, schrieb Dirk Eibach:
This is work in progress.
I publi
> This is work in progress.
>
> I published patches to enable DMA_buf P2P a few months ago, but now I'm
> waiting for the PCI subsystem to pick up core support for this.
Great news! Can you give me a link to this series so I can already have a look?
> I can prepare you a branch based on current
This is work in progress.
I published patches to enable DMA_buf P2P a few months ago, but now I'm waiting
for the PCI subsystem to pick up core support for this.
I can prepare you a branch based on current upstream kernel next week if you
want to test this.
Regards,
Christian.
Am 29.09.2018 0
I want to access GPU VRAM via PCIe P2P access, like DirectGMA but with
mainline drivers.
I can acquire a dmabuf from the GPU and pass it to my PCIe
framegrabber. But I don't see a way to get the PCIe bus address of the
video memory which I need for the P2P transfer. Is there already any
infrastruct
42 matches
Mail list logo
