On Mon, 23 Jul 2018 22:53:08 +0200,
Alex Deucher wrote:
>
> On Mon, Jul 23, 2018 at 10:50 AM, Takashi Iwai wrote:
> > Hi,
> >
> > this is a patch set to add the support of drm_audio_component for
> > AMD/ATI HDMI codecs. With the drm_audio_component, the HDMI/DP audio
> > hotplug and ELD
On Sat, Jul 21, 2018 at 11:30:27AM +0800, kbuild test robot wrote:
> Hi Rodrigo,
>
> It's probably a bug fix that unveils the link errors.
>
> tree: git://anongit.freedesktop.org/drm/drm-tip drm-tip
> head: 20532651221ed29af16e2db0a7ec8b9bd482c994
> commit:
On Mon, Jul 23, 2018 at 02:27:35PM -0700, matthew.s.atw...@intel.com wrote:
> From: Matt Atwood
>
> According to DP spec (2.9.3.1 of DP 1.4) if
> EXTENDED_RECEIVER_CAPABILITY_FIELD_PRESENT is set the addresses in DPCD
> 02200h through 0220Fh shall contain the DPRX's true capability. These
>
file derived from msm-next kernel uapi header.
Change-Id: Idcaa1ad6fc13e0c1d2d0a2e619121d2c5450f7da
---
Makefile.sources | 1 +
include/drm/msm_drm.h | 308 ++
2 files changed, 309 insertions(+)
create mode 100644 include/drm/msm_drm.h
From: Matt Atwood
According to DP spec (2.9.3.1 of DP 1.4) if
EXTENDED_RECEIVER_CAPABILITY_FIELD_PRESENT is set the addresses in DPCD
02200h through 0220Fh shall contain the DPRX's true capability. These
values will match 0h through Fh, except for DPCD_REV,
MAX_LINK_RATE,
From: Matt Atwood
This bit was added to DP Training Aux RD interval with DP 1.3. Via
descriptiion of the spec this field indicates the panels true
capabilities are described in DPCD address space 02200h through 022FFh.
v2: version comment update
v3: version comment correction, commit message
Am Freitag, den 20.07.2018, 09:55 +0200 schrieb Marcel Ziswiler:
> From: Marcel Ziswiler
>
> Actually report the error code from devm_regulator_get() which may as
> well just be a probe deferral.
This is still noisy, so while you are changing this I would prefer if
this wouldn't print the error
On Mon, Jul 23, 2018 at 10:50 AM, Takashi Iwai wrote:
> Hi,
>
> this is a patch set to add the support of drm_audio_component for
> AMD/ATI HDMI codecs. With the drm_audio_component, the HDMI/DP audio
> hotplug and ELD read-out can be achieved directly without the hardware
> access. The best
https://bugzilla.kernel.org/show_bug.cgi?id=200633
sybo...@gmail.com changed:
What|Removed |Added
Regression|No |Yes
--
You are receiving this mail
https://bugzilla.kernel.org/show_bug.cgi?id=200633
Bug ID: 200633
Summary: [Regression] VGA not being detected with R9 380 using
AMDGPU after 4.17 kernel update.
Product: Drivers
Version: 2.5
Kernel Version: 4.17
https://bugs.freedesktop.org/show_bug.cgi?id=106441
--- Comment #6 from Richard B. Kreckel ---
(In reply to Richard B. Kreckel from comment #5)
> It must be Xorg.
>
> I've upgradee to Xorg 1.20 (without upgrading anything else) from
> Debian/experimental and this problem has disappeared for
Hi Thomas,
Am Dienstag, 17. Juli 2018, 13:09:27 CEST schrieb Thomas Zimmermann:
> This patch unifies the naming of DRM functions for reference counting
> of struct drm_device. The resulting code is more aligned with the rest
> of the Linux kernel interfaces.
>
> Signed-off-by: Thomas Zimmermann
https://bugs.freedesktop.org/show_bug.cgi?id=106228
--- Comment #4 from David Francis ---
Created attachment 140795
--> https://bugs.freedesktop.org/attachment.cgi?id=140795=edit
Patch that should fix the problem
Could you try out this patch and check if it works? Thanks.
--
You are
Hello Alex,
other than adding a brief commit message to this patch,
Reviewed-by: Sinclair Yeh
On Fri, Jul 20, 2018 at 10:15:09PM +0100, Alexandru Gheorghe wrote:
> Signed-off-by: Alexandru Gheorghe
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 4 +---
> 1 file changed, 1 insertion(+), 3
On Sat, 2018-07-21 at 11:39 +0200, Lukas Wunner wrote:
> On Thu, Jul 19, 2018 at 08:08:15PM -0400, Lyude Paul wrote:
> > On Thu, 2018-07-19 at 09:49 +0200, Lukas Wunner wrote:
> > > On Wed, Jul 18, 2018 at 04:56:39PM -0400, Lyude Paul wrote:
> > > > When DP MST hubs get confused, they can
Hi Alexandru,
Thanks for the patch, for the vmwgfx part:
Reviewed-by: Deepak Rawat
>
> Signed-off-by: Alexandru Gheorghe cosmin.gheor...@arm.com>
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git
commit eb493fbc150f4a28151ae1ee84f24395989f3600 upstream
Currently nouveau doesn't actually expose the state debugfs file that's
usually provided for any modesetting driver that supports atomic, even
if nouveau is loaded with atomic=1. This is due to the fact that the
standard debugfs files that
Boris Brezillon writes:
> Async plane update is supposed to work only when updating the FB or FB
> position of an already enabled plane. That does not apply to requests
> where the plane was previously disabled or assigned to a different
> CTRC.
>
> Check old_plane_state->crtc value to make sure
commit e5d54f1935722f83df7619f3978f774c2b802cd8 upstream
A CRTC being enabled doesn't mean it's on! It doesn't even necessarily
mean it's being used. This fixes runtime PM leaks on the P50 I've got
next to me.
Signed-off-by: Lyude Paul
Cc: sta...@vger.kernel.org
Signed-off-by: Ben Skeggs
---
On Friday, 2018-07-20 13:33:29 +0200, Benjamin Gaignard wrote:
> This is a modetest like tool but using atomic API.
>
> With modetest_atomic it is mandatory to specify a mode ("-s")
> and a plane ("-P") to display a pattern on screen.
>
> "-v" does a loop swapping between two framebuffers for
https://bugs.freedesktop.org/show_bug.cgi?id=107296
--- Comment #2 from Paul Menzel ---
Adding print statements, it turns out, the second function
`verify_clock_values()` returns *false*.
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=107333
--- Comment #2 from Benjamin Hodgetts ---
By "forced" I mean I specified amdgpu.dc=0 on the kernel command line to force
DC off (as it's on by default).
Yes to the second part of your question. Using dc=0 allows the display to be
properly
https://bugs.freedesktop.org/show_bug.cgi?id=107333
--- Comment #1 from Alex Deucher ---
(In reply to Benjamin Hodgetts from comment #0)
> dc=0 (forced)
> HDMI-A-0 connected 1920x1080+0+0 (normal left inverted right x axis y
> axis)
> 0mm x 0mm
> 1920x1080 60.00*+ 50.00
Hi Dave,
I have a couple of small patches for malidp to be applied in drm-next.
They have arisen from the decision to switch the writeback connectors to
always connected.
Best regards,
Liviu
The following changes since commit 500775074f88d9cf5416bed2ca19592812d62c41:
Merge branch
This patch introduces the HDMI audio component binding like what i915
does to radeon driver. Unlike i915, we need only the hotplug
notification and the ELD query, hence the code is relatively simple,
just adding the hook at radeon_audio_enable() and giving the eld query
by copying the
Instead of calling mutex_unlock() at each error path multiple times,
take the standard goto-and-a-single-unlock approach. This will
simplify the code and make easier to find the unbalanced mutex locks.
No functional changes, but only the code readability improvement as a
preliminary work for
This patch introduces the HDMI audio component binding like what i915
does to amdgpu driver. Unlike i915, we need only the hotplug
notification and the ELD query, hence the code is relatively simple,
just adding the hook at each *_audio_enable() call and giving the eld
query by copying the
Hi,
this is a patch set to add the support of drm_audio_component for
AMD/ATI HDMI codecs. With the drm_audio_component, the HDMI/DP audio
hotplug and ELD read-out can be achieved directly without the hardware
access. The best point by that is that it makes the hotplug
notification working even
AMD/ATI HDMI codec drivers didn't have the audio component binding
like i915, but it worked only with the traditional HD-audio
unsolicited event for the HDMI hotplug detection and the ELD read-up
thereafter. This has been a problem in many ways: first of all, it
goes through the hardware event
https://bugs.freedesktop.org/show_bug.cgi?id=107324
--- Comment #11 from Christian König ---
The issue with commit 32167016076f714f0e35e287fbead7de0f1fb179 is that it fixed
things quite a bunch of people, but unfortunately also broke things for some
other.
So far we tried to mitigate problems
On Wed, Jun 27, 2018 at 11:14:47PM +0200, Enric Balletbo i Serra wrote:
> Add support to async updates of cursors by using the new atomic
> interface for that.
>
> Signed-off-by: Enric Balletbo i Serra
LGTM. Given rockchip hasn't weighed in on the patch, and that you've tested it
on real
When the suballocator was unable to provide a suitable buffer for the MMUv1
linear window, we roll back the GPU initialization. As the GPU is runtime
resumed at that point we need to clear the kernel cmdbuf suballoc entry to
properly skip any attempt to manipulate the cmdbuf when the GPU gets shut
https://bugs.freedesktop.org/show_bug.cgi?id=106707
--- Comment #10 from Martin Peres ---
New bug created: https://bugs.freedesktop.org/show_bug.cgi?id=107341
However, I would also like to documented that we can also see this bug in GLK:
https://bugs.freedesktop.org/show_bug.cgi?id=107296
--- Comment #1 from Paul Menzel ---
In today’s drm-tip this is:
[ 20.149515] WARNING: CPU: 0 PID: 347 at
drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dcn_calcs.c:1372
dcn_bw_update_from_pplib+0x16b/0x280 [amdgpu]
It looks like this is
https://bugs.freedesktop.org/show_bug.cgi?id=107341
Bug ID: 107341
Summary: [CI][BAT] igt@amdgpu/amd_prime@amd-to-i915 - fail -
Failed assertion: __vgem_fence_signal(fd, fence) == 0
due to setup time taking longer than 10s
https://bugs.freedesktop.org/show_bug.cgi?id=107341
Martin Peres changed:
What|Removed |Added
Whiteboard||ReadyForDev
--
You are receiving this
https://bugs.freedesktop.org/show_bug.cgi?id=106707
--- Comment #9 from Martin Peres ---
(In reply to Chris Wilson from comment #8)
> (In reply to Martin Peres from comment #7)
> > (In reply to Chris Wilson from comment #6)
> > > (In reply to Martin Peres from comment #5)
> > > >
https://bugs.freedesktop.org/show_bug.cgi?id=106707
Chris Wilson changed:
What|Removed |Added
Component|DRM/Intel |IGT
On Mon, 23 Jul 2018 10:09:25 -0400
Sean Paul wrote:
> On Mon, Jul 23, 2018 at 03:59:02PM +0200, Boris Brezillon wrote:
> > drm_atomic_helper_async_check() declares the plane, old_plane_state and
> > new_plane_state variables to iterate over all planes of the atomic
> > state and make sure only
On Mon, Jul 23, 2018 at 03:59:02PM +0200, Boris Brezillon wrote:
> drm_atomic_helper_async_check() declares the plane, old_plane_state and
> new_plane_state variables to iterate over all planes of the atomic
> state and make sure only one plane is enabled.
>
> Unfortunately gcc is not smart
On Mon, Jul 23, 2018 at 03:43:54PM +0200, Boris Brezillon wrote:
> Async plane update is supposed to work only when updating the FB or FB
> position of an already enabled plane. That does not apply to requests
> where the plane was previously disabled or assigned to a different
> CTRC.
>
> Check
On Thu, Jul 19, 2018 at 03:22:16AM +0300, Haneen Mohammed wrote:
> Implement the set_crc_source() callback.
> Compute CRC using crc32 on the visible part of the framebuffer.
> Use ordered workqueue to compute and add CRC at the end of a vblank.
>
> Use appropriate synchronization methods since
drm_atomic_helper_async_check() declares the plane, old_plane_state and
new_plane_state variables to iterate over all planes of the atomic
state and make sure only one plane is enabled.
Unfortunately gcc is not smart enough to figure out that the check on
n_planes is enough to guarantee that
On Thu, Jul 19, 2018 at 03:18:55AM +0300, Haneen Mohammed wrote:
> This patch map/unmap GEM backing memory to kernel address space
> in prepare/cleanup_fb respectively and cache the virtual address
> for later use.
>
> Signed-off-by: Haneen Mohammed
> ---
> Changes in v2:
> - use vkms_gem_vunmap
On Thu, Jul 19, 2018 at 03:18:03AM +0300, Haneen Mohammed wrote:
> This patch add the necessary functions to map/unmap GEM
> backing memory to the kernel's virtual address space.
>
> Signed-off-by: Haneen Mohammed
> ---
> Changes in v2:
> - add vkms_gem_vunmap
> - use vmap_count to guard against
Async plane update is supposed to work only when updating the FB or FB
position of an already enabled plane. That does not apply to requests
where the plane was previously disabled or assigned to a different
CTRC.
Check old_plane_state->crtc value to make sure async plane update is
allowed.
https://bugs.freedesktop.org/show_bug.cgi?id=107334
Bug ID: 107334
Summary: Artifacts in Unigine Valley with RX 580
Product: Mesa
Version: git
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
https://bugs.freedesktop.org/show_bug.cgi?id=107333
Bug ID: 107333
Summary: Display Not Detected If Powered Off When amdgpu.dc=1
Product: DRI
Version: XOrg git
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
https://bugs.freedesktop.org/show_bug.cgi?id=105684
--- Comment #35 from Paul Menzel ---
Jian, I am curious, did you find a way how to use the system? Did you return it
or put it in a corner?
--
You are receiving this mail because:
You are the assignee for the
This patch implements get_crc_sources callback, which returns list of
all the crc sources supported by driver in current platform.
Changes Since V1:
- move sources list per-crtc
- init sources-list only for gen3
Changes Since V2:
- Adopt to driver style
- Address other review comments from
This patch implements "verify_crc_source" callback function for
rcar drm driver.
Changes Since V1:
- avoid duplication of code
Changes Since V2:
- further optimize the code
Changes Since V3:
- Adopt to driver style
- Address review comments from Laurent Pinchart
Signed-off-by: Mahesh Kumar
Hi Michal,
Am Mittwoch, den 18.07.2018, 14:29 +0200 schrieb Michal Vokáč:
> Ahoj,
>
> I encountered an error in etnaviv driver on one of my two very similar SBCs.
> They have the same board design but slightly different HW configuration.
> SW configuration/setup is the same for both. Including
On Fri, Jul 20, 2018 at 10:15:00PM +0100, Alexandru Gheorghe wrote:
> There are a lot of drivers that subclass drm_plane_state, all of them
> duplicate the code that links toghether the plane with plane_state.
>
> On top of that, drivers that enable core properties also have to
> duplicate the
https://bugs.freedesktop.org/show_bug.cgi?id=107277
--- Comment #13 from Paul Menzel ---
(In reply to Michel Dänzer from comment #12)
> (In reply to Paul Menzel from comment #11)
> > > Does this patch help?
> >
> > It looks like it.
> >
> > Tested-by: Paul Menzel
>
> Cool, thanks for
On Fri, Jul 20, 2018 at 10:15:02PM +0100, Alexandru Gheorghe wrote:
> Signed-off-by: Alexandru Gheorghe
> ---
> drivers/gpu/drm/arm/malidp_planes.c | 7 ++-
> 1 file changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/arm/malidp_planes.c
>
On 07/19/2018 01:24 PM, Dan Carpenter wrote:
Reviewed-by: Dan Carpenter
regards,
dan carpenter
Applied to drm-misc-next
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
We do not need sun4i_backend_format_is_packed_yuv422() /
sun4i_backend_format_is_planar_yuv() to determine if the format is yuv multi
planar
or not. (struct drm_format_info *)->is_yuv tells if the format is yuv or not.
And (struct drm_format_info *)->num_planes denotes the number of planes.
This
On Fri 20-07-18 16:01:25, Andrew Morton wrote:
> On Tue, 17 Jul 2018 10:12:01 +0200 Michal Hocko wrote:
>
> > > Any suggestions regarding how the driver developers can test this code
> > > path? I don't think we presently have a way to fake an oom-killing
> > > event? Perhaps we should add
Hi Russell,
Am Dienstag, den 17.07.2018, 17:02 +0100 schrieb Russell King:
> Try a bit harder to produce a devcoredump when things go wrong. If we
> fail to allocate the memory for a dump including the actual bo contents,
> omit the bos and try again. Capturing some information from the GPU is
https://bugs.freedesktop.org/show_bug.cgi?id=107319
--- Comment #1 from Michel Dänzer ---
Please send patches like this directly to the amd-gfx mailing list for review.
--
You are receiving this mail because:
You are the assignee for the bug.___
https://bugs.freedesktop.org/show_bug.cgi?id=106670
Michel Dänzer changed:
What|Removed |Added
Resolution|--- |INVALID
Status|NEW
https://bugs.freedesktop.org/show_bug.cgi?id=107324
--- Comment #10 from Michel Dänzer ---
If the modprobe error happens only when nomodeset is on the kernel command
line, that's expected, as the radeon driver cannot work with nomodeset. Sounds
like the real issue here is the black screen
On Mon 23-07-18 09:11:54, Michal Hocko wrote:
> On Mon 23-07-18 09:03:06, Michal Hocko wrote:
> > On Fri 20-07-18 17:09:02, Andrew Morton wrote:
> > [...]
> > > Please take a look?
> >
> > Are you OK to have these in a separate patch?
>
> Btw. I will rebase this patch once oom stuff in
https://bugs.freedesktop.org/show_bug.cgi?id=107324
--- Comment #9 from jamesstewartmil...@gmail.com ---
Hey Christian Konig, thanks for all your hard work on the driver, I've been
checking bug 98046 which details something similar, and have seen your work on
improving the pll code, which I have
On Wed, 18 Jul 2018, Daniel Thompson wrote:
> On Wed, Jul 18, 2018 at 04:55:44PM +0100, Lee Jones wrote:
> > On Wed, 18 Jul 2018, Daniel Thompson wrote:
> >
> > > On Wed, Jul 18, 2018 at 02:08:53PM +0100, Lee Jones wrote:
> > > > > > > > No, then we are back to the initial issue of num_steps
> >
https://bugs.freedesktop.org/show_bug.cgi?id=107324
--- Comment #8 from jamesstewartmil...@gmail.com ---
Created attachment 140776
--> https://bugs.freedesktop.org/attachment.cgi?id=140776=edit
results log from ubuntu firmware checking tool
This is the output from the ubuntu firmware
https://bugs.freedesktop.org/show_bug.cgi?id=107324
--- Comment #7 from jamesstewartmil...@gmail.com ---
Created attachment 140775
--> https://bugs.freedesktop.org/attachment.cgi?id=140775=edit
dmesg output with radeon inserted via modprobe
dmesg output - I've attempted to modprobe the radeon
On Thu, 19 Jul 2018, Daniel Thompson wrote:
> Currently, if the DT does not define num-interpolated-steps then
> num_steps is undefined and the interpolation code will deploy randomly.
> Fix this.
>
> Additionally fix a small grammar error that was identified and
> tighten up return code
On 2018-07-20 18:53, Daniel Thompson wrote:
On 09/07/18 11:22, Kiran Gunda wrote:
Rename the PM8941* references as WLED3 to make the
driver generic and have WLED support for other PMICs.
Signed-off-by: Kiran Gunda
---
Changes from V3:
- Changed the MODULE_DESCRIPTION
On Mon, Jul 09, 2018 at 10:36:43AM +0200, Daniel Vetter wrote:
> #define for_each_active_drhd_unit(drhd)
> \
> list_for_each_entry_rcu(drhd, _drhd_units, list) \
> - if (drhd->ignored) {} else
> + for_each_if
In function virtio_gpu_conn_destroy a pointer to a containing structure
virtio_gpu_output is received using drm_connector_to_virtio_gpu_output
(container_of), and then it is passed to kfree function.
But this pointer points to a member of array (vgdev->outputs + index)
(see vgdev_output_init):
This modifies vbox_crtc_do_set_base() to take a new framebuffer to
be activated, instead of the existing framebuffer attached to the crtc.
This change allows the function to be given the new framebuffer from
a page-flip request.
Signed-off-by: Steve Longerbeam
---
On Mon, Jan 01, 2018 at 12:17:35PM +, Russell King - ARM Linux wrote:
> On Wed, Dec 13, 2017 at 06:22:14PM +0200, Ville Syrjälä wrote:
> > On Wed, Dec 13, 2017 at 11:12:18AM -0500, Ilia Mirkin wrote:
> > > On Wed, Dec 13, 2017 at 10:41 AM, Daniel Stone
> > > wrote:
> > > > Hi Russell,
> > >
On Wed 2018-07-18 19:49:10, Andy Shevchenko wrote:
> On Tue, Jul 17, 2018 at 3:59 AM, Dmitry Safonov wrote:
> > I would be glad if someone helps/bothers to review the change :C
> >
>
> Perhaps Petr and / or Steven can help you.
> > Thanks,
> > Dmitry
> >
> > On Tue, 2018-07-03 at 23:56 +0100,
在 2018-07-18三的 18:26 +0530，Jagan Teki写道：
> On Wed, Jul 18, 2018 at 6:14 PM, Maxime Ripard
> wrote:
> > On Wed, Jul 18, 2018 at 04:24:40PM +0530, Jagan Teki wrote:
> > > Allwinner A64 has display engine pipeline like other Allwinner
> > > SOC's A83T/H3/H5.
> > >
> > > A64 behaviour similar to
On 2018-07-20 19:37, Daniel Thompson wrote:
On 09/07/18 11:22, Kiran Gunda wrote:
Handle the short circuit interrupt and check if the short circuit
interrupt is valid. Re-enable the module to check if it goes
away. Disable the module altogether if the short circuit event
persists.
Attaching CRTC to a connector increases its reference count, preventing
it from correct deinitialization. Following kernel log is printed when
the leak is found:
Console: switching to colour VGA+ 80x25
WARNING: at drivers/gpu/drm/drm_mode_config.c:431
...
Call
Adds crtc page-flip support by passing the new requested framebuffer
to vbox_crtc_do_set_base().
There is no attempt to support vblank interrupts, so this page-flip
implementation does not try to sync the page-flip to vertical blanking,
so expect tearing effects. Is it possible to access the host
On Thu 2018-07-19 12:16:00, Thomas Zimmermann wrote:
> The macro WARN_CONSOLE_UNLOCKED prints a warning when a thread enters
> the console's critical section without having acquired the console
> lock. The console lock can be ignored when debugging the console using
> printk, but this makes
In function virtio_gpufb_create, a virtio_gpu_object is allocated for
framebuffer using virtio_gpu_alloc_object.
In virtio_gpu_fbdev_destroy, instead of freeing the object, pointer to
it is set to NULL. This leads to memory leak during framebuffer
destruction, which is reported to kmesg with a
On 07/20/2018 05:01 AM, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> This work is in response to my previous attempt to introduce Xen/DRM
> zero-copy driver [1] to enable Linux dma-buf API [2] for Xen based
> frontends/backends. There is also an existing hyper_dmabuf
On Thu 2018-07-19 12:16:01, Thomas Zimmermann wrote:
> If the console is unlocked during registration, the console subsystem
> generates significant amounts of warnings, which obfuscate actual
> debugging messages. Setting ignore_console_lock_warning while debugging
> console registration avoid
Adds crtc page-flip support by passing the new requested framebuffer
to vbox_crtc_do_set_base().
Note there is no attempt to support vblank interrupts, it's not
not known how to do this in VBOX or if it is even possible. Since
this page-flip implementation does not try to sync the page-flip
to
Hi Maxime,
Dne sreda, 11. julij 2018 ob 10:30:36 CEST je Maxime Ripard napisal(a):
> On Tue, Jul 10, 2018 at 10:34:53PM +0200, Jernej Skrabec wrote:
> > This series fixes several issues found in R40 HDMI patch series after
> > it was applied. Conversation can be found here:
> >
Module parameter virtio_gpu_fbdev is used to enable or disable fbdev in
virtio. It is checked during fbdev initialization, but is not checked
during deinitialization.
Moving fbdev destruction to virtgpu_kms.c instead of virtgpu_display.c
places deinitialization to the same file as initialization,
From: Marcel Ziswiler
Actually report the error code from devm_regulator_get() which may as
well just be a probe deferral.
Signed-off-by: Marcel Ziswiler
---
drivers/gpu/drm/tegra/hdmi.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git
On Fri, 2018-07-20 at 17:09 +0200, Petr Mladek wrote:
> > > On Tue, 2018-07-03 at 23:56 +0100, Dmitry Safonov wrote:
> > > > Currently ratelimit_state is protected with spin_lock. If the
> > > > .lock
> > > > is
> > > > taken at the moment of ___ratelimit() call, the message is
> > > > suppressed
On 2018-07-21 02:51, Pavel Machek wrote:
Hi!
>@@ -332,6 +529,7 @@ static u32 wled_values(const struct wled_var_cfg *cfg, u32
idx)
> }
> #define WLED3 3
>+#defineWLED4 4
Are these macros always going to define 3 to be 3 and 4 to be 4. If so
we
probably don't need them (and they
This series of patches aims to fix some bugs and memory leaks
in virtio-gpu deinitialization paths.
While denitialization paths is not usually executed in any virtio-gpu
usecase, it is useful for testing during implementation of virtio-gpu
device part.
Damir Shaikhutdinov (4):
drm/virtio: Fix
From: Randy Dunlap
Fix indentation warning (from gcc 8.1.0) in omap2/omapfb:
../drivers/video/fbdev/omap2/omapfb/dss/dispc.c: In function 'pixinc':
../drivers/video/fbdev/omap2/omapfb/dss/dispc.c:1859:2: warning: this 'else'
clause does not guard... [-Wmisleading-indentation]
else
^~~~
On Mon 23-07-18 09:03:06, Michal Hocko wrote:
> On Fri 20-07-18 17:09:02, Andrew Morton wrote:
> [...]
> > Please take a look?
>
> Are you OK to have these in a separate patch?
Btw. I will rebase this patch once oom stuff in linux-next settles. At
least oom_lock removal from oom_reaper will
On Fri 20-07-18 17:09:02, Andrew Morton wrote:
[...]
> Please take a look?
Are you OK to have these in a separate patch?
--
Michal Hocko
SUSE Labs
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
92 matches
Mail list logo
