When receiving video it is very useful to be able to log DP VSC SDP.
This greatly simplifies debugging.
v2: Minor style fix
v3: Move logging functions to drm core [Jani N]
v5: Rebased
Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/drm_dp_helper.c | 174
In order to use computed config for DP SDPs (DP VSC SDP and DP HDR Metadata
Infoframe SDP), it replaces intel_dp_vsc_enable() function and
intel_dp_hdr_metadata_enable() function to intel_dp_set_infoframes()
function.
And it removes unused functions.
Before:
intel_dp_vsc_enable() and
Dump out the HDMI Dynamic Range and Mastering (DRM) infoframe in the
normal crtc state dump.
Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_display.c | 3 +++
1 file changed, 3 insertions(+)
diff --git
It adds an unpack only function for DRM infoframe for dynamic range and
mastering infoframe readout.
It unpacks the information data block contained in the binary buffer into
a structured frame of the HDMI Dynamic Range and Mastering (DRM)
information frame.
In contrast to
In order to use a common VSC SDP Colorimetry calculating code on PSR,
it adds a compute routine for PSR VSC SDP.
As PSR routine can not use infoframes.vsc of crtc state, it also adds new
writing of DP SDPs (Secondary Data Packet) for PSR.
PSR routine has its own scenario and timings of writing a
It stores computed dp hdr metadata infoframe sdp to infoframes.drm of
crtc state. It referenced intel_hdmi_compute_drm_infoframe().
While computing, we'll also fill out the infoframes.enable bitmask
appropriately.
v2: Wrap a long line.
v4: Use struct drm_device logging macros
v5: Fix typo [Uma]
Dump out the DP VSC SDP in the normal crtc state dump
v3: Replace a structure name to drm_dp_vsc_sdp from intel_dp_vsc_sdp
Use drm core's DP VSC SDP logging function
Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_display.c | 13 +
In order to use a common VSC SDP Colorimetry calculating code on PSR,
it uses a new psr vsc sdp compute routine.
Because PSR routine has its own scenario and timings of writing a VSC SDP,
the current PSR routine needs to have its own drm_dp_vsc_sdp structure
member variable on struct i915_psr.
In
Call intel_dp_set_infoframes() function on pipe updates to make sure
that we send VSC SDP and HDR Metadata Infoframe SDP (when applicable)
on fastsets.
Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_ddi.c | 1 +
1 file changed, 1 insertion(+)
It adds code to read the DP SDPs from the video DIP and unpack them into
the crtc state.
It adds routines that read out DP VSC SDP and DP HDR Metadata Infoframe SDP
In order to unpack DP VSC SDP, it adds intel_dp_vsc_sdp_unpack() function.
It follows DP 1.4a spec. [Table 2-116: VSC SDP Header
Added state readout for DP HDR Metadata Infoframe SDP.
Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_ddi.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
It adds routines that write DP VSC SDP and DP HDR Metadata Infoframe SDP.
In order to pack DP VSC SDP, it adds intel_dp_vsc_sdp_pack() function.
It follows DP 1.4a spec. [Table 2-116: VSC SDP Header Bytes] and
[Table 2-117: VSC SDP Payload for DB16 through DB18]
In order to pack DP HDR Metadata
Dump out the DP HDR Metadata Infoframe SDP in the normal crtc state dump.
HDMI Dynamic Range and Mastering (DRM) infoframe and DP HDR Metadata
Infoframe SDP use the same member variable in infoframes of crtc state.
Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Uma Shankar
---
Added state readout for DP VSC SDP and enabled state validation
for DP VSC SDP.
v2: Minor style fix
v3: Replace a structure name to drm_dp_vsc_sdp from intel_dp_vsc_sdp
v4: Use struct drm_device logging macros
Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Uma Shankar
---
It adds new enumeration definitions for VSC SDP Payload for Pixel
Encoding/Colorimetry Format.
And it adds a new drm data structure for DP VSC SDP.
enum dp_colorspace and enum dp_colorimetry correspond "Pixel Encoding and
Colorimetry Formats". enum dp_dynamic_range corresponds "Dynamic Range".
Compared to implementation of DP and HDMI's encoder->infoframes_enabled,
the lspcon's implementation returns its active state. (we expect enabled
infoframe states of HW.) It leads to pipe state mismatch error
when ddi_get_config is called.
Because the current implementation of lspcon is not ready
Call intel_dp_set_infoframes(false) function on intel_ddi_post_disable_dp()
to make sure not to send VSC SDP and HDR Metadata Infoframe SDP.
v5: Polish commit message [Uma]
Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_ddi.c | 2 ++
1 file
In order to support state readout for DP VSC SDP, we need to have a
structure which holds DP VSC SDP payload data such as
"union hdmi_infoframe drm" which is used for DRM infoframe.
It adds a struct drm_dp_vsc_sdp vsc to intel_crtc_state.infoframes.
And it stores computed dp vsc sdp to
In order to readout DP SDPs (Secondary Data Packet: DP HDR Metadata
Infoframe SDP, DP VSC SDP), it refactors handling DP SDPs codes.
It adds new compute routines for DP HDR Metadata Infoframe SDP
and DP VSC SDP.
And new writing routines of DP SDPs (Secondary Data Packet) that uses
computed
On 31/07/2019 12:42, Peter Ujfalusi wrote:
Hi,
two small correction on the use of DMAengine API, no functional changes
- Use dmaengine_prep_dma_memcpy() to prepare the memcpy
- do not call dma_async_issue_pending() as it is redundant
Regards,
Peter
---
Peter Ujfalusi (2):
drm/omap:
On 09/12/2019 14:33, Kieran Bingham wrote:
Fix trivial spelling identified while examining the code.
s/supprted./supported./
Signed-off-by: Kieran Bingham
---
drivers/gpu/drm/omapdrm/omap_crtc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
On 23/01/2020 09:05, Zheng Bin wrote:
Fixes coccicheck warning:
drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c:681:1-15: WARNING: Assignment
of 0/1 to bool variable
drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c:732:1-15: WARNING: Assignment
of 0/1 to bool variable
Reported-by: Hulk Robot
On 2020-02-07 19:40, Jeffrey Hugo wrote:
On Fri, Feb 7, 2020 at 5:38 AM wrote:
On 2020-02-06 20:29, Jeffrey Hugo wrote:
> On Thu, Feb 6, 2020 at 2:13 AM Harigovindan P
> wrote:
>>
>> For a given byte clock, if VCO recalc value is exactly same as
>> vco set rate value, vco_set_rate does not
A recent commit in clang added -Wtautological-compare to -Wall, which is
enabled for i915 so we see the following warning:
../drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:1485:22: warning:
result of comparison of constant 576460752303423487 with expression of
type 'unsigned int' is always false
A20 SoC (found in Cubieboard 2 among others) requires different LVDS set
up procedure than A33. Timing controller (tcon) driver only implements
sun6i-style procedure, that doesn't work on A20 (sun7i).
The support for such procedure is ported from u-boot and follows u-boot
naming convention:
A recent commit in clang added -Wtautological-compare to -Wall, which is
enabled for i915 so we see the following warning:
../drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:1485:22: warning:
result of comparison of constant 576460752303423487 with expression of
type 'unsigned int' is always false
From: Emmanuel Vadot
Change the licence to a dual one with MIT so BSDs could use this file.
Signed-off-by: Emmanuel Vadot
---
drivers/gpu/drm/drm_client.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_client.c b/drivers/gpu/drm/drm_client.c
index
Hi,
On Mon, Feb 10, 2020 at 09:56:33PM +0200, Andrey Lebedev wrote:
> A20 SoC (found in Cubieboard 2 among others) requires different LVDS set
> up procedure than A33. Timing controller (tcon) driver only implements
> sun6i-style procedure, that doesn't work on A20 (sun7i).
You're missing your
From: Emmanuel Vadot
Change the licence to a dual one with MIT so BSDs could use this file.
Signed-off-by: Emmanuel Vadot
---
drivers/gpu/drm/drm_format_helper.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_format_helper.c
Hello all,
We had a discussion a while back with Noralf where he said that he wouldn't
mind dual licence his work under GPL-2 and MIT.
Those files are a problem with BSDs as we cannot include them.
For drm_client.c the main contributors are Noralf Trønnes and Thomas
Zimmermann, the other commits
comments inline
> 2020年2月11日 13:26，Pan, Xinhui 写道：
>
> comments inline.
> [xh]
>
>
>> 2020年2月10日 23:09，Christian König 写道：
>>
>> This patch reworks the whole delayed deletion of BOs which aren't idle.
>>
>> Instead of having two counters for the BO structure we resurrect the BO
>> when we
Hi
I'm surprised that prepare_fb is called with fb == NULL. But, OK
Acked-by: Thomas Zimmermann
Thanks for the fix.
Am 11.02.20 um 00:09 schrieb James Jones:
> This fixes a kernel oops when loading the nouveau
> module with fb console enabled after the change:
>
> drm/nouveau: Remove field
comments inline.
[xh]
> 2020年2月10日 23:09，Christian König 写道：
>
> This patch reworks the whole delayed deletion of BOs which aren't idle.
>
> Instead of having two counters for the BO structure we resurrect the BO
> when we find that a deleted BO is not idle yet.
>
> This has many advantages,
https://bugzilla.kernel.org/show_bug.cgi?id=206309
--- Comment #1 from Travis Juntara (changhaitra...@gmail.com) ---
So I just got a Dell E-series docking station, and I've just noticed that if I
boot while docked, I get the full performance.
I'll test sometime to see if the AC power brick
On Mon, 2020-02-10 at 09:10 -0500, Sean Paul wrote:
> On Sun, Feb 9, 2020 at 9:53 PM CK Hu wrote:
> >
> > Hi, Evan:
> >
> > On Fri, 2020-02-07 at 16:34 +0800, CK Hu wrote:
> > > Hi, Evan:
> > >
> > > On Fri, 2020-02-07 at 15:23 +1100, Evan Benn wrote:
> > > > The cursor and primary planes were
On Tue, 11 Feb 2020 at 09:17, James Jones wrote:
>
> On 2/10/20 12:25 AM, Thomas Zimmermann wrote:
> > Hi
> >
> > Am 10.02.20 um 09:20 schrieb Ben Skeggs:
> >> On Sat, 8 Feb 2020 at 07:10, James Jones wrote:
> >>>
> >>> I've sent out a v4 version of the format modifier patches which avoid
> >>>
On 2/10/20 12:25 AM, Thomas Zimmermann wrote:
Hi
Am 10.02.20 um 09:20 schrieb Ben Skeggs:
On Sat, 8 Feb 2020 at 07:10, James Jones wrote:
I've sent out a v4 version of the format modifier patches which avoid
caching values in the nouveau_framebuffer struct. It will have a few
trivial
Allow setting the block layout of a nouveau FB
object using DRM format modifiers. When
specified, the format modifier block layout and
kind overrides the GEM buffer's implicit layout
and kind. The specified format modifier is
validated against the list of modifiers supported
by the target
Make sure framebuffer dimensions and tiling
parameters will not result in accesses beyond the
end of the GEM buffer they are bound to.
v3: Return EINVAL when creating FB against BO with
unsupported tiling
v5: Resolved against nouveau_framebuffer cleanup
Signed-off-by: James Jones
---
This series modifies the NV5x+ nouveau display backends to advertise
appropriate format modifiers on their display planes in atomic mode
setting blobs.
Corresponding modifications to Mesa/userspace are available on the
Mesa-dev gitlab merge request 3724:
Advertise support for the full list of format
modifiers supported by each class of NVIDIA
desktop GPU display hardware. Stash the array
of modifiers in the nouveau_display struct for
use when validating userspace framebuffer
creation requests, which will be supportd in
a subsequent change.
This fixes a kernel oops when loading the nouveau
module with fb console enabled after the change:
drm/nouveau: Remove field nvbo from struct nouveau_framebuffer
state->fb may be NULL in nv50_wndw_prepare_fb(),
so defer initializing nvbo from its obj[] array
until after the NULL check.
On Mon, Feb 10, 2020 at 8:01 PM Emil Velikov wrote:
>
> Thanks for having a look Daniel.
>
> On Fri, 7 Feb 2020 at 13:29, Daniel Vetter wrote:
> >
> > On Wed, Feb 05, 2020 at 05:48:39PM +, Emil Velikov wrote:
> > > From: Emil Velikov
> > >
> > > This commit reworks the permission handling
Hi Lucas,
Thank you for bringing awareness of this issue, publicly.
As soon as this patch showed up back in November of 2019,
I objected to it, privately.
I suggested to instead use a _list_ to store the "state" of
all jobs of the same state. Then, at any time, timeout interrupt
or whatever, we
Hi,
On Sun, Feb 9, 2020 at 11:41 PM Sharat Masetty wrote:
>
> This patch adds the required dt nodes and properties
> to enabled A618 GPU.
>
> Signed-off-by: Sharat Masetty
In v4 I added my tags [1]. Please keep them for future patches unless
something major changes. AKA:
Reviewed-by:
https://bugzilla.kernel.org/show_bug.cgi?id=206475
Marco (rodomar...@protonmail.com) changed:
What|Removed |Added
Status|NEW |RESOLVED
https://bugzilla.kernel.org/show_bug.cgi?id=203905
--- Comment #7 from Sandor Ecker (esa...@freemail.hu) ---
I have upgraded to 5.6.rc1:
uname -a
Linux Aspire-A315-41 5.6.0-050600rc1-generic #202002092032 SMP Mon Feb 10
01:36:50 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
I have seen that the code
Thanks for having a look Daniel.
On Fri, 7 Feb 2020 at 13:29, Daniel Vetter wrote:
>
> On Wed, Feb 05, 2020 at 05:48:39PM +, Emil Velikov wrote:
> > From: Emil Velikov
> >
> > This commit reworks the permission handling of the two ioctls. In
> > particular it enforced the CAP_SYS_ADMIN
In order to use a common VSC SDP Colorimetry calculating code on PSR,
it uses a new psr vsc sdp compute routine.
Because PSR routine has its own scenario and timings of writing a VSC SDP,
the current PSR routine needs to have its own drm_dp_vsc_sdp structure
member variable on struct i915_psr.
In
Dump out the DP VSC SDP in the normal crtc state dump
v3: Replace a structure name to drm_dp_vsc_sdp from intel_dp_vsc_sdp
Use drm core's DP VSC SDP logging function
Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_display.c | 13 +
Call intel_dp_set_infoframes() function on pipe updates to make sure
that we send VSC SDP and HDR Metadata Infoframe SDP (when applicable)
on fastsets.
Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_ddi.c | 1 +
1 file changed, 1 insertion(+)
Call intel_dp_set_infoframes(false) function on intel_ddi_post_disable_dp()
to make sure not to send VSC SDP and HDR Metadata Infoframe SDP.
v5: Polish commit message [Uma]
Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_ddi.c | 2 ++
1 file
In order to use a common VSC SDP Colorimetry calculating code on PSR,
it adds a compute routine for PSR VSC SDP.
As PSR routine can not use infoframes.vsc of crtc state, it also adds new
writing of DP SDPs (Secondary Data Packet) for PSR.
PSR routine has its own scenario and timings of writing a
Compared to implementation of DP and HDMI's encoder->infoframes_enabled,
the lspcon's implementation returns its active state. (we expect enabled
infoframe states of HW.) It leads to pipe state mismatch error
when ddi_get_config is called.
Because the current implementation of lspcon is not ready
In order to use computed config for DP SDPs (DP VSC SDP and DP HDR Metadata
Infoframe SDP), it replaces intel_dp_vsc_enable() function and
intel_dp_hdr_metadata_enable() function to intel_dp_set_infoframes()
function.
And it removes unused functions.
Before:
intel_dp_vsc_enable() and
Added state readout for DP VSC SDP and enabled state validation
for DP VSC SDP.
v2: Minor style fix
v3: Replace a structure name to drm_dp_vsc_sdp from intel_dp_vsc_sdp
v4: Use struct drm_device logging macros
Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Uma Shankar
---
Added state readout for DP HDR Metadata Infoframe SDP.
Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_ddi.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
Dump out the HDMI Dynamic Range and Mastering (DRM) infoframe in the
normal crtc state dump.
Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_display.c | 3 +++
1 file changed, 3 insertions(+)
diff --git
In order to support state readout for DP VSC SDP, we need to have a
structure which holds DP VSC SDP payload data such as
"union hdmi_infoframe drm" which is used for DRM infoframe.
It adds a struct drm_dp_vsc_sdp vsc to intel_crtc_state.infoframes.
And it stores computed dp vsc sdp to
Dump out the DP HDR Metadata Infoframe SDP in the normal crtc state dump.
HDMI Dynamic Range and Mastering (DRM) infoframe and DP HDR Metadata
Infoframe SDP use the same member variable in infoframes of crtc state.
Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Uma Shankar
---
It adds routines that write DP VSC SDP and DP HDR Metadata Infoframe SDP.
In order to pack DP VSC SDP, it adds intel_dp_vsc_sdp_pack() function.
It follows DP 1.4a spec. [Table 2-116: VSC SDP Header Bytes] and
[Table 2-117: VSC SDP Payload for DB16 through DB18]
In order to pack DP HDR Metadata
It adds code to read the DP SDPs from the video DIP and unpack them into
the crtc state.
It adds routines that read out DP VSC SDP and DP HDR Metadata Infoframe SDP
In order to unpack DP VSC SDP, it adds intel_dp_vsc_sdp_unpack() function.
It follows DP 1.4a spec. [Table 2-116: VSC SDP Header
When receiving video it is very useful to be able to log DP VSC SDP.
This greatly simplifies debugging.
v2: Minor style fix
v3: Move logging functions to drm core [Jani N]
v5: Rebased
Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/drm_dp_helper.c | 174
It adds an unpack only function for DRM infoframe for dynamic range and
mastering infoframe readout.
It unpacks the information data block contained in the binary buffer into
a structured frame of the HDMI Dynamic Range and Mastering (DRM)
information frame.
In contrast to
It stores computed dp hdr metadata infoframe sdp to infoframes.drm of
crtc state. It referenced intel_hdmi_compute_drm_infoframe().
While computing, we'll also fill out the infoframes.enable bitmask
appropriately.
v2: Wrap a long line.
v4: Use struct drm_device logging macros
v5: Fix typo [Uma]
In order to readout DP SDPs (Secondary Data Packet: DP HDR Metadata
Infoframe SDP, DP VSC SDP), it refactors handling DP SDPs codes.
It adds new compute routines for DP HDR Metadata Infoframe SDP
and DP VSC SDP.
And new writing routines of DP SDPs (Secondary Data Packet) that uses
computed
It adds new enumeration definitions for VSC SDP Payload for Pixel
Encoding/Colorimetry Format.
And it adds a new drm data structure for DP VSC SDP.
enum dp_colorspace and enum dp_colorimetry correspond "Pixel Encoding and
Colorimetry Formats". enum dp_dynamic_range corresponds "Dynamic Range".
(adding back Daniel)
Den 10.02.2020 17.57, skrev Noralf Trønnes:
>
>
> Den 10.02.2020 16.06, skrev Daniel Vetter:
>> On Mon, Feb 10, 2020 at 12:37:52PM +0100, Gerd Hoffmann wrote:
>>> Move final cleanups to qxl_drm_release() callback.
>>> Add drm_atomic_helper_shutdown() call to
Den 10.02.2020 16.06, skrev Daniel Vetter:
> On Mon, Feb 10, 2020 at 12:37:52PM +0100, Gerd Hoffmann wrote:
>> Move final cleanups to qxl_drm_release() callback.
>> Add drm_atomic_helper_shutdown() call to qxl_pci_remove().
>>
>> Signed-off-by: Gerd Hoffmann
>> ---
>>
Lucas - Ping on my question and also I attached this temporary solution
for etnaviv to clarify my point. If that something acceptable for now at
least i can do the same for v3d where it requires a bit more code changes.
Andrey
On 2/6/20 10:49 AM, Andrey Grodzovsky wrote:
Well a revert would
https://bugzilla.kernel.org/show_bug.cgi?id=206475
--- Comment #4 from Marco (rodomar...@protonmail.com) ---
Created attachment 287277
--> https://bugzilla.kernel.org/attachment.cgi?id=287277=edit
dmesg for amd-drm-next
--
You are receiving this mail because:
You are watching the assignee of
https://bugzilla.kernel.org/show_bug.cgi?id=206475
--- Comment #3 from Marco (rodomar...@protonmail.com) ---
Same thing with linux-amd-drm-next, dmesg attached. Any pointers to the cause?
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=205169
--- Comment #26 from Alex Deucher (alexdeuc...@gmail.com) ---
Patch has been upstream for a while:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0e29be9e0bbbf9cb3d718c5c48382b1420ce0749
--
You are receiving this
On Mon, Feb 10, 2020 at 05:44:19PM +0200, Jyri Sarha wrote:
> On 10/02/2020 15:21, Ville Syrjälä wrote:
> > On Sun, Feb 09, 2020 at 02:50:09PM +0200, Jyri Sarha wrote:
> >> On 07/02/2020 20:45, Ville Syrjälä wrote:
> >>> On Fri, Feb 07, 2020 at 08:26:17PM +0200, Jyri Sarha wrote:
> On
On 10/02/2020 15:21, Ville Syrjälä wrote:
> On Sun, Feb 09, 2020 at 02:50:09PM +0200, Jyri Sarha wrote:
>> On 07/02/2020 20:45, Ville Syrjälä wrote:
>>> On Fri, Feb 07, 2020 at 08:26:17PM +0200, Jyri Sarha wrote:
On 07/02/2020 20:18, Jyri Sarha wrote:
> The old implementation of placing
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_hw_sequencer.c:
In function dcn10_post_unlock_program_front_end:
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_hw_sequencer.c:2623:29:
warning: variable stream_status set but not used [-Wunused-but-set-variable]
commit bbf5f6c3f83b
Hi Dave, Daniel,
Now that -rc1 is out, here's the first drm-misc-next PR. All things
considered it's been pretty quiet, the diffstat being scary mostly
because of the conversion of device tree bindings to YAML and a new
driver.
Maxime
drm-misc-next-2020-02-10:
drm-misc-next for 5.7:
UAPI
Hello there,
linux-5.6-rc1/drivers/gpu/drm/amd/display/modules/hdcp/hdcp1_execution.c:33:33:
error: Buffer is accessed out of bounds: hdcp->auth.msg.hdcp1.bksv
[bufferAccessOutOfBounds]
Source code is
memcpy(, hdcp->auth.msg.hdcp1.bksv, sizeof(uint64_t));
Field bksv is only five bytes
Commit f5a98bfe7b37 ("dt-bindings: display: Convert Allwinner display
pipeline to schemas") introduced a YAML schema for the Allwinner TCON DT
binding, but the H6 TCON-TV compatible was mistakenly set to fallback on
the A83t's, while the initial documentation and the DT are using R40's.
Fix that.
Hello there,
Source code is
unsigned int vsync_rate_hz = 0;
struct dc_static_screen_params params = {0};
/* Calculate number of static frames before generating interrupt to
* enter PSR.
*/
unsigned int frame_time_microsec = 100 / vsync_rate_hz;
Suggest code rework.
The function is always called with deleted BOs.
While at it cleanup the indentation as well.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 12 +++-
1 file changed, 3 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c
When non-imported BOs are resurrected for delayed delete we replace
the dma_resv object to allow for easy reclaiming of the resources.
v2: move that to ttm_bo_individualize_resv
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 10 +-
1 file changed, 9 insertions(+), 1
This allows release_notify to add and remove fences from deleted objects.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index
This patch reworks the whole delayed deletion of BOs which aren't idle.
Instead of having two counters for the BO structure we resurrect the BO
when we find that a deleted BO is not idle yet.
This has many advantages, especially that we don't need to
increment/decrement the BOs reference counter
This series of patches cleans up TTMs delayed delete handling.
The core of the new handling is that we new only have a single reference
counter instead of two and use kref_get_unless_zero() to grab BOs from the LRU
during eviction.
This reduces the overhead of LRU moves and allows us to
This allows it to call the function without the lock held.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index c1104c8857b7..e12fc2c2d165
Ghost BOs need to stick with the resv object only when the origin is imported.
This is a low hanging fruit to avoid OOM situations on evictions.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo_util.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
On Mon, Feb 10, 2020 at 12:37:52PM +0100, Gerd Hoffmann wrote:
> Move final cleanups to qxl_drm_release() callback.
> Add drm_atomic_helper_shutdown() call to qxl_pci_remove().
>
> Signed-off-by: Gerd Hoffmann
> ---
> drivers/gpu/drm/qxl/qxl_drv.c | 26 +++---
> 1 file
On Mon, Feb 10, 2020 at 10:38:01AM +0100, Gerd Hoffmann wrote:
> Call drm_dev_unregister() first in bochs_pci_remove(). Hook
> bochs_unload() into the new .release callback, to make sure cleanup
> is done when all users are gone.
>
> Add ready bool to state struct and move bochs_hw_fini() call
On Mon, 10 Feb 2020 at 11:15, Linus Walleij wrote:
>
> The PWM backlight still supports passing a enable GPIO line as
> platform data using the legacy API.
>
> It turns out that ever board using this mechanism except one
> is pass .enable_gpio = -1. So we drop all these cargo-culted -1's
> from
On Sun, Feb 9, 2020 at 9:53 PM CK Hu wrote:
>
> Hi, Evan:
>
> On Fri, 2020-02-07 at 16:34 +0800, CK Hu wrote:
> > Hi, Evan:
> >
> > On Fri, 2020-02-07 at 15:23 +1100, Evan Benn wrote:
> > > The cursor and primary planes were hard coded.
> > > Now search for them for passing to
On Mon, Feb 10, 2020 at 11:15:46AM +0100, Linus Walleij wrote:
> The PWM backlight still supports passing a enable GPIO line as
> platform data using the legacy API.
>
> It turns out that ever board using this mechanism except one
> is pass .enable_gpio = -1. So we drop all these cargo-culted
On Fri, Feb 07, 2020 at 01:26:24PM +0800, Nicolas Boichat wrote:
> Some GPUs, namely, the bifrost/g72 part on MT8183, have a second
> regulator for their SRAM, let's add support for that.
Reviwed-by: Mark Brown
signature.asc
Description: PGP signature
On Sun, Feb 09, 2020 at 02:50:09PM +0200, Jyri Sarha wrote:
> On 07/02/2020 20:45, Ville Syrjälä wrote:
> > On Fri, Feb 07, 2020 at 08:26:17PM +0200, Jyri Sarha wrote:
> >> On 07/02/2020 20:18, Jyri Sarha wrote:
> >>> The old implementation of placing planes on the CRTC while configuring
> >>> the
https://bugzilla.kernel.org/show_bug.cgi?id=206475
--- Comment #2 from Marco (rodomar...@protonmail.com) ---
Created attachment 287275
--> https://bugzilla.kernel.org/attachment.cgi?id=287275=edit
amdgpu crash with stock kernel
--
You are receiving this mail because:
You are watching the
https://bugzilla.kernel.org/show_bug.cgi?id=206475
--- Comment #1 from Marco (rodomar...@protonmail.com) ---
Just tested under 5.5.2 stock kernel (besides ZFS module) and the same problem
show up. Log attached.
--
You are receiving this mail because:
You are watching the assignee of the bug.
On Mon, Feb 10, 2020 at 11:15:04AM +0100, Linus Walleij wrote:
> The code in the Corgi backlight driver can be considerably
> simplified by moving to GPIO descriptors and lookup tables
> from the board files instead of passing GPIO numbers using
> the old API.
>
> Make sure to encode inversion
On 07/02/2020 05:26, Nicolas Boichat wrote:
> When there is a single power domain per device, the core will
> ensure the power domain is switched on (so it is technically
> equivalent to having not power domain specified at all).
>
> However, when there are multiple domains, as in MT8183 Bifrost
Gerd Hoffmann (2):
drm/qxl: reorder calls in qxl_device_fini().
drm/qxl: add drm_driver.release callback.
drivers/gpu/drm/qxl/qxl_drv.c | 26 +++---
drivers/gpu/drm/qxl/qxl_kms.c | 8
2 files changed, 23 insertions(+), 11 deletions(-)
--
2.18.1
Reorder calls in qxl_device_fini(). Cleaning up gem & ttm
might trigger qxl commands, so we should do that before
releaseing command rings.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_kms.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git
1 - 100 of 152 matches
Mail list logo
