Hi Laurent,
I like the approach, current practice when almost every bridge should
optionally implement connector, or alternatively downstream bridge or
panel is very painful.
More comments inlined.
On 07.07.2019 20:18, Laurent Pinchart wrote:
> To support implementation of DRM connectors on top
Use the "probe" nomenclature for consistency with internally used names
of functions and variables.
Requires adjustment of IGT tests and possibly affects other user custom
applications.
Signed-off-by: Janusz Krzysztofik
---
drivers/gpu/drm/i915/i915_drv.c| 10 +-
Replace mixed "_fini"/"_cleanup"/"_cleanup_hw" suffixes found in names
of fucntions called from i915_driver_release() with "_release" suffix
consistently. This provides better code readability, especially
helpful when trying to work out which phase the code is in.
Functions names starting with
Need for this was identified while working on split of driver unbind
path into _remove() and _release() parts. Consistency in function
naming has been recognized as helpful when trying to work out which
phase the code is in.
What I'm still not sure about is desired depth of that modification -
Use the "_probe" nomenclature not only in i915_driver_probe() helper
name but also in other related function / variable names for
consistency. Only the userspace exposed name of a related module
parameter is left untouched.
Signed-off-by: Janusz Krzysztofik
---
Current names of i915_driver_load/unload() functions originate in
legacy DRM stubs. Reduce nomenclature ambiguity by renaming them to
match their current use as helpers called from PCI entry points.
Suggested by: Chris Wilson
Signed-off-by: Janusz Krzysztofik
---
Similar to the "_release" case, consistently replace mixed
"_cleanup"/"_fini"/"_fini_hw" components found in names of functions
called from i915_driver_remove() with "_remove" or "_driver_remove"
suffixes for better code readability.
Signed-off-by: Janusz Krzysztofik
---
If the LED is acquired by a consumer device with devm_led_get(), it is
automatically release when the device is detach.
Signed-off-by: Jean-Jacques Hiblot
---
drivers/leds/led-class.c | 42
include/linux/leds.h | 2 ++
2 files changed, 44
10.07.2019 13:12, Maxime Ripard пишет:
> On Tue, Jul 09, 2019 at 05:51:51PM +0300, Dmitry Osipenko wrote:
>> The named mode could be invalid and then cmdline parser misses to validate
>> mode's dimensions, happily adding 0x0 mode as a valid mode. One case where
>> this happens is NVIDIA Tegra
From: Ville Syrjälä
Sparse complains:
../drivers/gpu/drm/drm_syncobj.c:942:13: warning: symbol
'drm_timeout_abs_to_jiffies' was not declared. Should it be static?
Include the correct header with the prototype.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_syncobj.c | 1 +
1 file
From: Ville Syrjälä
Sparse complains:
drivers/gpu/drm/drm_fb_helper.c:2409:12: warning: symbol
'drm_fb_helper_modinit' was not declared. Should it be static?
Include the header with the correct prototype.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_fb_helper.c | 1 +
1 file
From: Ville Syrjälä
Sparse compains:
../drivers/gpu/drm/drm_debugfs_crc.c:350:17: warning: incorrect type in
initializer (different base types)
../drivers/gpu/drm/drm_debugfs_crc.c:350:17:expected restricted __poll_t (
*poll )( ... )
../drivers/gpu/drm/drm_debugfs_crc.c:350:17:got
https://bugs.freedesktop.org/show_bug.cgi?id=109538
--- Comment #1 from gregory shu ---
I'm doing it the other way around hevc_vaapi 10 bit to h264_vaapi and have
similar results, garbled green output
ffmpeg -threads 4 \
-init_hw_device vaapi=amd:/dev/dri/renderD128 -hwaccel vaapi
Hi Sam,
since you've been picking up some panel patches lately, might I ask you
to take a look at this patch?
Regards,
Lucas
Am Freitag, den 14.12.2018, 14:20 +0100 schrieb Lucas Stach:
> Hi Thierry,
>
> can you please have a look at this one?
>
> Regards,
> Lucas
>
> Am Montag, den
10.07.2019 16:06, Maxime Ripard пишет:
> On Wed, Jul 10, 2019 at 03:59:55PM +0300, Dmitry Osipenko wrote:
>> 10.07.2019 15:55, Maxime Ripard пишет:
>>> On Wed, Jul 10, 2019 at 03:42:28PM +0300, Dmitry Osipenko wrote:
10.07.2019 13:12, Maxime Ripard пишет:
> On Tue, Jul 09, 2019 at
10.07.2019 16:11, Dmitry Osipenko пишет:
> 10.07.2019 16:06, Maxime Ripard пишет:
>> On Wed, Jul 10, 2019 at 03:59:55PM +0300, Dmitry Osipenko wrote:
>>> 10.07.2019 15:55, Maxime Ripard пишет:
On Wed, Jul 10, 2019 at 03:42:28PM +0300, Dmitry Osipenko wrote:
> 10.07.2019 13:12, Maxime
On Wed, Jul 10, 2019 at 03:07:40PM +0200, Lucas Stach wrote:
> Hi Sam,
>
> since you've been picking up some panel patches lately, might I ask you
> to take a look at this patch?
>
> Regards,
> Lucas
>
> Am Freitag, den 14.12.2018, 14:20 +0100 schrieb Lucas Stach:
> > Hi Thierry,
> >
> > can
Similar to the "_release" and "_remove" cases, consequently replace
"_init" components of names of functions called from
i915_driver_probe() with "_probe" suffixes for better code readability.
Signed-off-by: Janusz Krzysztofik
---
drivers/gpu/drm/i915/i915_drv.c | 26 +-
From: Tomi Valkeinen
This patch adds basic support for a kernel driver to get a LED device.
This will be used by the led-backlight driver.
Only OF version is implemented for now, and the behavior is similar to
PWM's of_pwm_get() and pwm_put().
Signed-off-by: Tomi Valkeinen
Signed-off-by:
From: Tomi Valkeinen
This patch adds a led-backlight driver (led_bl), which is similar to
pwm_bl except the driver uses a LED class driver to adjust the
brightness in the HW. Multiple LEDs can be used for a single backlight.
Signed-off-by: Tomi Valkeinen
Signed-off-by: Jean-Jacques Hiblot
---
Add DT binding for led-backlight.
Signed-off-by: Jean-Jacques Hiblot
---
.../bindings/leds/backlight/led-backlight.txt | 28 +++
1 file changed, 28 insertions(+)
create mode 100644
Documentation/devicetree/bindings/leds/backlight/led-backlight.txt
diff --git
This series aims to add a led-backlight driver, similar to pwm-backlight,
but using a LED class device underneath.
A few years ago (2015), Tomi Valkeinen posted a series implementing a
backlight driver on top of a LED device:
https://patchwork.kernel.org/patch/7293991/
Quoting Janusz Krzysztofik (2019-07-10 13:36:25)
> Need for this was identified while working on split of driver unbind
> path into _remove() and _release() parts. Consistency in function
> naming has been recognized as helpful when trying to work out which
> phase the code is in.
>
> What I'm
From: Ville Syrjälä
__be16 = cpu_to_be16(__be16) is nonsense. Do it right.
../drivers/gpu/drm/drm_dsc.c:218:53: warning: incorrect type in assignment
(different base types)
../drivers/gpu/drm/drm_dsc.c:218:53:expected restricted __be16
../drivers/gpu/drm/drm_dsc.c:218:53:got int
From: Ville Syrjälä
Sparse is not happy:
../drivers/gpu/drm/drm_memory.c:159:6: warning: symbol 'drm_need_swiotlb' was
not declared. Should it be static?
Include the correct header for drm_need_swiotlb() prototype.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_memory.c | 1 +
1 file
On Wed, Jul 10, 2019 at 03:42:28PM +0300, Dmitry Osipenko wrote:
> 10.07.2019 13:12, Maxime Ripard пишет:
> > On Tue, Jul 09, 2019 at 05:51:51PM +0300, Dmitry Osipenko wrote:
> >> The named mode could be invalid and then cmdline parser misses to validate
> >> mode's dimensions, happily adding 0x0
On Wednesday, July 10, 2019 2:47:08 PM CEST Chris Wilson wrote:
> Quoting Janusz Krzysztofik (2019-07-10 13:36:25)
> > Need for this was identified while working on split of driver unbind
> > path into _remove() and _release() parts. Consistency in function
> > naming has been recognized as
10.07.2019 15:55, Maxime Ripard пишет:
> On Wed, Jul 10, 2019 at 03:42:28PM +0300, Dmitry Osipenko wrote:
>> 10.07.2019 13:12, Maxime Ripard пишет:
>>> On Tue, Jul 09, 2019 at 05:51:51PM +0300, Dmitry Osipenko wrote:
The named mode could be invalid and then cmdline parser misses to validate
On Wed, Jul 10, 2019 at 03:59:55PM +0300, Dmitry Osipenko wrote:
> 10.07.2019 15:55, Maxime Ripard пишет:
> > On Wed, Jul 10, 2019 at 03:42:28PM +0300, Dmitry Osipenko wrote:
> >> 10.07.2019 13:12, Maxime Ripard пишет:
> >>> On Tue, Jul 09, 2019 at 05:51:51PM +0300, Dmitry Osipenko wrote:
>
Hi Laurent.
I had assumed this driver would look like the other Topology driver, but
they differ a lot. So it makes sense to have different drivers.
This driver implements suspend/resume.
But the correct way would be to implment prepare/unprepare.
The power_on(), power_off() functions would
10.07.2019 16:29, Dmitry Osipenko пишет:
> 10.07.2019 16:11, Dmitry Osipenko пишет:
>> 10.07.2019 16:06, Maxime Ripard пишет:
>>> On Wed, Jul 10, 2019 at 03:59:55PM +0300, Dmitry Osipenko wrote:
10.07.2019 15:55, Maxime Ripard пишет:
> On Wed, Jul 10, 2019 at 03:42:28PM +0300, Dmitry
Hi Dave & Daniel,
Some rather important fixes that appeared after -rc6 and
missed v5.2. As a PR by request of Daniel.
These avoid one WARN and potential dirty pointer deref,
fix a regression on saturated media loads and add missing
Icelake W/As.
I've manually added Cc: stable to all of them.
Hi Josef.
On Mon, Jul 08, 2019 at 04:56:17PM +0200, Josef Lusticky wrote:
> ILI9341 supports both SPI input mode and parallel RGB input mode.
> This commit adds parallel RGB input mode bindings.
>
> Signed-off-by: Josef Lusticky
> ---
> .../bindings/display/ilitek,ili9341.txt | 67
On 5/24/19 4:36 AM, Jani Nikula wrote:
On Thu, 23 May 2019, tcamuso wrote:
From Daniel Kwon
The system was crashed due to invalid memory access while trying to access
auxiliary device.
crash> bt
PID: 9863 TASK: 89d1bdf11040 CPU: 1 COMMAND: "ipmitool"
#0 [89cedd7f3868]
Hi Josef.
Thanks for updating the driver.
On Mon, Jul 08, 2019 at 04:56:18PM +0200, Josef Lusticky wrote:
> Add driver for Ilitek ILI9341 panels in parallel RGB mode
>
> Signed-off-by: Josef Lusticky
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
>
https://bugs.freedesktop.org/show_bug.cgi?id=110659
--- Comment #26 from Michel Dänzer ---
(In reply to tempel.julian from comment #25)
> I also reported the bug to the wine devs (still I think this is rather a bug
> of xf86-video-amdgpu):
It's a kernel issue, not an xf86-video-amdgpu one.
--
Hi Josef.
On Mon, Jul 08, 2019 at 04:56:16PM +0200, Josef Lusticky wrote:
> Hi,
> This is the v2 of the patch-set which adds support for
> Ilitek ILI9341 parallel RGB panels.
>
> The ILI9341 chip supports both parallel RGB input mode and SPI input mode.
> This driver adds support for the
On Wed, Jul 10, 2019 at 09:47:11AM -0400, Tony Camuso wrote:
> On 5/24/19 4:36 AM, Jani Nikula wrote:
> > On Thu, 23 May 2019, tcamuso wrote:
> >> From Daniel Kwon
> >>
> >> The system was crashed due to invalid memory access while trying to access
> >> auxiliary device.
> >>
> >> crash> bt
>
10.07.2019 13:00, Ville Syrjälä пишет:
> On Tue, Jul 09, 2019 at 05:51:51PM +0300, Dmitry Osipenko wrote:
>> The named mode could be invalid and then cmdline parser misses to validate
>> mode's dimensions, happily adding 0x0 mode as a valid mode. One case where
>> this happens is NVIDIA Tegra
On Wed, Jul 10, 2019 at 04:29:19PM +0300, Dmitry Osipenko wrote:
> This works:
>
> diff --git a/drivers/gpu/drm/drm_client_modeset.c
> b/drivers/gpu/drm/drm_client_modeset.c
> index 56d36779d213..e5a2f9c8f404 100644
> --- a/drivers/gpu/drm/drm_client_modeset.c
> +++
https://bugs.freedesktop.org/show_bug.cgi?id=109955
--- Comment #48 from Mauro Gaspari ---
@Sam,
Thank you, this is helpful. Since it is not distribution specific and not mesa
related, do you think we should keep the bug here, merge it with other similar
bugs, or create on other bug tracking?
From: Lucas Stach
[ Upstream commit be132e1375c1fffe48801296279079f8a59a9ed3 ]
When something goes wrong in the GPU init after the cmdbuf suballocator
has been constructed, we fail to destroy it properly. This causes havok
later when the GPU is unbound due to a module unload or similar.
Fixes:
From: Robert Beckett
[ Upstream commit 78c68e8f5cd24bd32ba4ca1cdfb0c30cf0642685 ]
Notify drm core before sending pending events during crtc disable.
This fixes the first event after disable having an old stale timestamp
by having drm_crtc_vblank_off update the timestamp to now.
This was seen
From: Lucas Stach
[ Upstream commit be132e1375c1fffe48801296279079f8a59a9ed3 ]
When something goes wrong in the GPU init after the cmdbuf suballocator
has been constructed, we fail to destroy it properly. This causes havok
later when the GPU is unbound due to a module unload or similar.
Fixes:
On Fri, Jul 05, 2019 at 12:41:03PM +, Philippe CORNU wrote:
> Hi Olivier,
> and many thanks for your patch.
> Good to have the audio graph card support, looks ok.
> Reviewed-by: Philippe Cornu
Since you have drm-misc commit rights I'm assuming you're going to push
this too. Correct?
-Daniel
On Mon, Jul 08, 2019 at 04:39:45PM +0300, Pekka Paalanen wrote:
> On Wed, 26 Jun 2019 18:27:54 +0200
> Daniel Vetter wrote:
>
> > On Wed, Jun 26, 2019 at 04:40:13PM +0200, Sam Ravnborg wrote:
> > > Hi Gerd.
> > >
> > > On Wed, Jun 26, 2019 at 08:55:50AM +0200, Gerd Hoffmann wrote:
> > > >
10.07.2019 18:45, Dmitry Osipenko пишет:
> 10.07.2019 18:05, Dmitry Osipenko пишет:
>> 10.07.2019 17:05, Maxime Ripard пишет:
>>> On Wed, Jul 10, 2019 at 04:29:19PM +0300, Dmitry Osipenko wrote:
This works:
diff --git a/drivers/gpu/drm/drm_client_modeset.c
On Tue, Jul 09, 2019 at 10:55:14PM -0300, Rodrigo Siqueira wrote:
> Currently, vkms only work with enabled VBlank. This patch adds another
> operation model that allows vkms to work without VBlank support. In this
> scenario, vblank signaling is faked by calling drm_send_vblank_event()
> in
Minor cleanup to remove extra return statement.
Signed-off-by: Souptick Joarder
---
drivers/video/fbdev/nvidia/nv_backlight.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/video/fbdev/nvidia/nv_backlight.c
b/drivers/video/fbdev/nvidia/nv_backlight.c
index e705a78..2ce5352 100644
On Wed, 2019-07-10 at 17:31 +0200, Daniel Vetter wrote:
> On Thu, Jul 04, 2019 at 11:54:10AM +0300, Oleg Vasilev wrote:
> > Bring dmabuf sharing through implementing prime_import_sg_table
> > callback.
> > This will help to validate userspace conformance in prime
> > configurations
> > without
From: "Steven Rostedt (VMware)"
Currently the intel_update_plane and intel_disable_plane tracepoints record
the address of plane->name in the ring buffer, and then when reading the
ring buffer uses %s to get the name. The issue with this, is that those two
events can be minutes, hours or even
On Mon, Jul 8, 2019 at 11:18 AM Bjorn Andersson
wrote:
>
> On Wed 03 Jul 07:00 PDT 2019, Rob Clark wrote:
>
> > From: Rob Clark
> >
> > For platforms that require the "zap shader" to take the GPU out of
> > secure mode at boot, we also need the zap fw to end up in the initrd.
> >
> >
On Wed 2019-07-10 14:39:32, Jean-Jacques Hiblot wrote:
> From: Tomi Valkeinen
>
> This patch adds a led-backlight driver (led_bl), which is similar to
> pwm_bl except the driver uses a LED class driver to adjust the
> brightness in the HW. Multiple LEDs can be used for a single backlight.
>
>
Quoting Janusz Krzysztofik (2019-07-10 15:52:39)
> Follow dim checkpatch recommendation so it doesn't complain on that now
> and again on header file modifications.
>
> Signed-off-by: Janusz Krzysztofik
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@
On Sun, Jul 07, 2019 at 06:14:50PM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 07.07.19 um 16:37 schrieb Noralf Trønnes:
> >
> >
> > Den 05.07.2019 11.26, skrev Thomas Zimmermann:
> >> Generic framebuffer emulation uses a shadow buffer for framebuffers with
> >> dirty() function. If drivers
On Wed, Jul 10, 2019 at 03:38:13PM +, Vasilev, Oleg wrote:
> On Wed, 2019-07-10 at 18:35 +0300, Oleg Vasilev wrote:
> > On Wed, 2019-07-10 at 17:31 +0200, Daniel Vetter wrote:
> > > On Thu, Jul 04, 2019 at 11:54:10AM +0300, Oleg Vasilev wrote:
> > > > Bring dmabuf sharing through implementing
Quoting Janusz Krzysztofik (2019-07-10 15:59:55)
> Follow dim checkpatch recommendations so it doesn't complain now and
> again on consistent modifications of i915_params.c
This is one where we've considered the merits of not rigorously applying
checkpatch.pl and adopted a different convention.
Thanks for doing this patch!
On Wed, Jul 03, 2019 at 10:02:59PM +, Maya Rashish wrote:
> ---
We can't apply this patch because it doesn't follow necassary form (sob
line missing). Please check out:
On Wed, Jul 10, 2019 at 11:25:49AM -0400, Steven Rostedt wrote:
> I was doing a bit of an audit on trace events and found this:
>
> # cat /debug/tracing/events/i915/intel_disable_plane/format
> name: intel_disable_plane
> ID: 1358
> format:
> field:unsigned short common_type;
On Wed 2019-07-10 14:39:31, Jean-Jacques Hiblot wrote:
> Add DT binding for led-backlight.
>
> Signed-off-by: Jean-Jacques Hiblot
> ---
> .../bindings/leds/backlight/led-backlight.txt | 28 +++
> 1 file changed, 28 insertions(+)
> create mode 100644
>
On Wed 2019-07-10 14:39:30, Jean-Jacques Hiblot wrote:
> If the LED is acquired by a consumer device with devm_led_get(), it is
> automatically release when the device is detach.
released, detached.
Acked-by: Pavel Machek
Follow dim checkpatch recommendation so it doesn't complain on that now
and again on header file modifications.
Signed-off-by: Janusz Krzysztofik
---
drivers/gpu/drm/i915/gem/i915_gem_object.h | 2 +-
drivers/gpu/drm/i915/gvt/gtt.h | 13 +++---
drivers/gpu/drm/i915/i915_drv.h
On Thu, Jul 04, 2019 at 11:54:10AM +0300, Oleg Vasilev wrote:
> Bring dmabuf sharing through implementing prime_import_sg_table callback.
> This will help to validate userspace conformance in prime configurations
> without using any actual hardware (e.g. in the cloud).
>
> Cc: Rodrigo Siqueira
>
10.07.2019 18:05, Dmitry Osipenko пишет:
> 10.07.2019 17:05, Maxime Ripard пишет:
>> On Wed, Jul 10, 2019 at 04:29:19PM +0300, Dmitry Osipenko wrote:
>>> This works:
>>>
>>> diff --git a/drivers/gpu/drm/drm_client_modeset.c
>>> b/drivers/gpu/drm/drm_client_modeset.c
>>> index
On Wed, 2019-07-10 at 10:43 +0100, Russell King - ARM Linux admin wrote:
> On Wed, Jul 10, 2019 at 11:17:31AM +0200, Johannes Berg wrote:
> > On Tue, 2019-07-09 at 22:04 -0700, Joe Perches wrote:
> > > These GENMASK uses are inverted argument order and the
> > > actual masks produced are
On Sun, Jul 07, 2019 at 09:07:53PM +0300, Laurent Pinchart wrote:
> The drm_display_info structure contains many fields related to HDMI
> sinks, but none that identifies if a sink compliant with CEA-861 (EDID)
> shall be treated as an HDMI sink or a DVI sink. Add such a flag, and
> populate it
On Wed, 10 Jul 2019 18:45:24 +0300
Ville Syrjälä wrote:
> > TP_printk("pipe %c, plane %s, frame=%u, scanline=%u",
> > pipe_name(__entry->pipe), __entry->name,
> > __entry->frame, __entry->scanline)
> >
> >
> > The issue here is that you record a
On Wed 2019-07-10 14:39:29, Jean-Jacques Hiblot wrote:
> From: Tomi Valkeinen
>
> This patch adds basic support for a kernel driver to get a LED device.
> This will be used by the led-backlight driver.
>
> Only OF version is implemented for now, and the behavior is similar to
> PWM's
On Mon, Jul 08, 2019 at 10:18:16AM +0200, Sam Ravnborg wrote:
> Hi Maya.
>
> Nice catch - good to remove unused cruft.
>
> Please prefix the subject with something like "drm/agp: ".
> Check "git log" on the same file to pick up the usual way to identify
> agp specific changes.
>
> With this
On Mon, Jul 01, 2019 at 12:23:39AM -0300, Rodrigo Siqueira wrote:
> This patchset introduces the support for configfs in vkms by adding a
> primary structure for handling the vkms subsystem and exposing
> connectors as a use case. This series allows enabling/disabling virtual
> and writeback
I was doing a bit of an audit on trace events and found this:
# cat /debug/tracing/events/i915/intel_disable_plane/format
name: intel_disable_plane
ID: 1358
format:
field:unsigned short common_type; offset:0; size:2;
signed:0;
field:unsigned char common_flags;
On Wed, 2019-07-10 at 18:35 +0300, Oleg Vasilev wrote:
> On Wed, 2019-07-10 at 17:31 +0200, Daniel Vetter wrote:
> > On Thu, Jul 04, 2019 at 11:54:10AM +0300, Oleg Vasilev wrote:
> > > Bring dmabuf sharing through implementing prime_import_sg_table
> > > callback.
> > > This will help to validate
Hi Derek.
On Tue, Jul 09, 2019 at 07:16:55PM -0700, Derek Basehore wrote:
> This adds the plumbing for reading panel rotation from the devicetree
> and sets up adding a panel property for the panel orientation on
> Mediatek SoCs when a rotation is present.
>
> v7 changes:
> -forgot to add static
https://bugs.freedesktop.org/show_bug.cgi?id=01
Bug ID: 01
Summary: kernel warning with 2400G
Product: DRI
Version: XOrg git
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Severity: normal
This is dead code since 3.15. If there is no plan to use it
further, this can be removed forever.
Signed-off-by: Souptick Joarder
---
drivers/video/fbdev/nvidia/nv_setup.c | 24
1 file changed, 24 deletions(-)
diff --git a/drivers/video/fbdev/nvidia/nv_setup.c
https://bugs.freedesktop.org/show_bug.cgi?id=109955
--- Comment #49 from Wilko Bartels ---
(In reply to Sam from comment #47)
> The relevant issue and bug report here (the system freezing completely or if
> lucky just killing the X session, NOT games crashing) seems to be related
> exclusively
https://bugs.freedesktop.org/show_bug.cgi?id=110659
--- Comment #27 from tempel.jul...@gmail.com ---
(In reply to Michel Dänzer from comment #26)
> It's a kernel issue, not an xf86-video-amdgpu one.
Thanks for clarifying.
I could also reproduce this issue with Doom OpenGL in Steam Play/Proton
From: Gerd Hoffmann
[ Upstream commit 41de4be6f6efa4132b29af51158cd672d93f2543 ]
drm_connector_update_edid_property can sleep, we must not
call it while holding a spinlock. Move the callsite.
Fixes: b4b01b4995fb ("drm/virtio: add edid support")
Reported-by: Max Filippov
Signed-off-by: Gerd
From: Robert Beckett
[ Upstream commit 5aeab2bfc9ffa72d3ca73416635cb3785dfc076f ]
The event will be sent as part of the vblank enable during the modeset
if the crtc is not being kept disabled.
Fixes: 5f2f911578fb ("drm/imx: atomic phase 3 step 1: Use atomic configuration")
Signed-off-by:
From: Robert Beckett
[ Upstream commit 78c68e8f5cd24bd32ba4ca1cdfb0c30cf0642685 ]
Notify drm core before sending pending events during crtc disable.
This fixes the first event after disable having an old stale timestamp
by having drm_crtc_vblank_off update the timestamp to now.
This was seen
From: Robert Beckett
[ Upstream commit 78c68e8f5cd24bd32ba4ca1cdfb0c30cf0642685 ]
Notify drm core before sending pending events during crtc disable.
This fixes the first event after disable having an old stale timestamp
by having drm_crtc_vblank_off update the timestamp to now.
This was seen
From: Robert Beckett
[ Upstream commit 5aeab2bfc9ffa72d3ca73416635cb3785dfc076f ]
The event will be sent as part of the vblank enable during the modeset
if the crtc is not being kept disabled.
Fixes: 5f2f911578fb ("drm/imx: atomic phase 3 step 1: Use atomic configuration")
Signed-off-by:
From: Robert Beckett
[ Upstream commit 5aeab2bfc9ffa72d3ca73416635cb3785dfc076f ]
The event will be sent as part of the vblank enable during the modeset
if the crtc is not being kept disabled.
Fixes: 5f2f911578fb ("drm/imx: atomic phase 3 step 1: Use atomic configuration")
Signed-off-by:
From: Robert Beckett
[ Upstream commit 78c68e8f5cd24bd32ba4ca1cdfb0c30cf0642685 ]
Notify drm core before sending pending events during crtc disable.
This fixes the first event after disable having an old stale timestamp
by having drm_crtc_vblank_off update the timestamp to now.
This was seen
From: Robert Beckett
[ Upstream commit 5aeab2bfc9ffa72d3ca73416635cb3785dfc076f ]
The event will be sent as part of the vblank enable during the modeset
if the crtc is not being kept disabled.
Fixes: 5f2f911578fb ("drm/imx: atomic phase 3 step 1: Use atomic configuration")
Signed-off-by:
On Wed, 2019-07-10 at 08:45 -0700, Joe Perches wrote:
> On Wed, 2019-07-10 at 10:43 +0100, Russell King - ARM Linux admin wrote:
> > On Wed, Jul 10, 2019 at 11:17:31AM +0200, Johannes Berg wrote:
> > > On Tue, 2019-07-09 at 22:04 -0700, Joe Perches wrote:
> > > > These GENMASK uses are inverted
Follow dim checkpatch recommendations so it doesn't complain now and
again on consistent modifications of i915_params.c
Signed-off-by: Janusz Krzysztofik
---
drivers/gpu/drm/i915/i915_params.c | 96 ++
1 file changed, 33 insertions(+), 63 deletions(-)
diff --git
On Tue, Jul 09, 2019 at 03:20:58PM +0200, Andrzej Hajda wrote:
> On 07.07.2019 20:07, Laurent Pinchart wrote:
> > The drm_display_info structure contains many fields related to HDMI
> > sinks, but none that identifies if a sink compliant with CEA-861 (EDID)
> > shall be treated as an HDMI sink or
From: "Steven Rostedt (VMware)"
Currently the intel_update_plane and intel_disable_plane tracepoints record
the address of plane->name in the ring buffer, and then when reading the
ring buffer uses %s to get the name. The issue with this, is that those two
events can be minutes, hours or even
Some small nitpicks
On Thu, 2019-07-04 at 15:05 -0400, sunpeng...@amd.com wrote:
> From: Ville Syrjälä
>
> All available downstream ports - physical and logical - are exposed for
> each MST device. They are listed in /dev/, following the same naming
> scheme as SST devices by appending an
On Wed, Jul 10, 2019 at 4:40 AM Maxime Ripard wrote:
>
> On Tue, Jul 09, 2019 at 01:30:18PM -0700, Vasily Khoruzhick wrote:
> > On Tue, Jul 9, 2019 at 1:55 AM Maxime Ripard
> > wrote:
> > >
> > > On Mon, Jul 08, 2019 at 05:49:21PM -0700, Vasily Khoruzhick wrote:
> > > > > > Maybe instead of
gah. So, I was originally going to ask "why didn't we add the connector name
into this?", but then I realized we're doing the right thing already and just
doing card%d-%s % (card_number, path_prop). Which means we probably really don't
want to add a property called mstpath, since it's hardly
Hi,
On Mon, Jul 8, 2019 at 10:56 AM Sam Ravnborg wrote:
>
> On Mon, Jul 01, 2019 at 09:39:06AM -0700, Doug Anderson wrote:
> > Hi,
> >
> > On Sun, Jun 30, 2019 at 1:55 PM Sam Ravnborg wrote:
> > >
> > > Hi Douglas.
> > >
> > > > > +
> > > > > + /* Only add timings if override was not there or
(adding sunpeng...@amd.com to the thread here, since this is relevant to the DP
aux device work)
I mentioned this in IRC, but figured I should mention it on the ML as well so it
can be discussed further. Honestly: I don't like the way we implement the path
prop for MST. Mainly because
* It
Max backlight value for the panel was being calculated using byte
count i.e. 0x if 2 bytes are supported for backlight brightness
and 0xff if 1 byte is supported. However, EDP_PWMGEN_BIT_COUNT
determines the number of active control bits used for the brightness
setting. Thus, even if the panel
On Tue, Jul 9, 2019 at 11:01 AM Brendan Higgins
wrote:
>
> On Tue, Jul 9, 2019 at 7:53 AM shuah wrote:
> >
> > On 7/9/19 12:30 AM, Brendan Higgins wrote:
> > > Add myself as maintainer of KUnit, the Linux kernel's unit testing
> > > framework.
> > >
> > > Signed-off-by: Brendan Higgins
> > >
On Thu, Jul 4, 2019 at 11:46 AM Chia-I Wu wrote:
>
> On Thu, Jul 4, 2019 at 4:25 AM Gerd Hoffmann wrote:
> >
> > Hi,
> >
> > > > if (fence)
> > > > virtio_gpu_fence_emit(vgdev, hdr, fence);
> > > > + if (vbuf->objs) {
> > > > +
Sam,
On Mon, Jul 8, 2019 at 10:50 AM Sam Ravnborg wrote:
>
> Hi Dough.
>
> On Mon, Jul 01, 2019 at 09:39:24AM -0700, Doug Anderson wrote:
> > Hi,
> >
> > On Sun, Jun 30, 2019 at 1:22 PM Sam Ravnborg wrote:
> > >
> > > > @@ -91,6 +92,8 @@ struct panel_simple {
> > > > struct i2c_adapter
On Thu, 2019-07-04 at 15:05 -0400, sunpeng...@amd.com wrote:
> From: Ville Syrjälä
>
> All available downstream ports - physical and logical - are exposed for
> each MST device. They are listed in /dev/, following the same naming
> scheme as SST devices by appending an incremental ID.
>
>
The rotation mode from cmdline shouldn't be taken into account if it
wasn't specified in the cmdline. This fixes ignored default display
orientation when display mode is given using cmdline without the
rotation being specified.
Fixes: 1bf4e09227c3 ("drm/modes: Allow to specify rotation and
1 - 100 of 163 matches
Mail list logo
