Am 08.04.20 um 23:24 schrieb Chris Wilson:
> drm_fbdev_generic_setup() was changed to be a void return, but the stub
> was left returning 0.
>
> ./include/drm/drm_fb_helper.h: In function ‘drm_fbdev_generic_setup’:
> ./include/drm/drm_fb_helper.h:450:9: warning: ‘return’ with a value, in
> func
From: Aditya Swarup
This function sets the VRR property for connector based
on the platform support, EDID monitor range and DP sink
DPCD capability of outputing video without msa
timing information.
v4:
* Rebase (Mansi)
v3:
* intel_dp_is_vrr_capable can be used for debugfs, make it
non static (M
DP sink device sets the Ignore MSA bit in its
DP_DOWNSTREAM_PORT_COUNT register to indicate its ability to
ignore the MSA video timing parameters and its ability to support
seamless video timing change over a range of timing exposed by
DisplayID and EDID.
This is required for the sink to indicate t
From: Bhanuprakash Modem
[Why]
It's useful to know the min and max vrr range for IGT testing.
[How]
Expose the min and max vfreq for the connector via a debugfs file
on the connector, "i915_vrr_info".
Example usage: cat /sys/kernel/debug/dri/0/DP-1/i915_vrr_info
v3:
* Remove the unnecessary de
tree: git://anongit.freedesktop.org/drm/drm-tip drm-tip
head: 636ab52e6d1d7aced9620f16da90d4c3c5fcadf5
commit: 213a0a26eba646607e88120c3fd27dc32b03e1f0 [6/8] Merge remote-tracking
branch 'drm-intel/topic/core-for-CI' into drm-tip
config: x86_64-defconfig (attached as .config)
compiler: clang v
Hi Hadar,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on stm32/stm32-next]
[also build test ERROR on sunxi/sunxi/for-next tegra/for-next linus/master
v5.7-rc1 next-20200413]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the
Hi Hadar,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on stm32/stm32-next]
[also build test ERROR on linus/master v5.7-rc1 next-20200413]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use
Hi Hadar,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on stm32/stm32-next]
[also build test ERROR on sunxi/sunxi/for-next tegra/for-next linus/master
v5.7-rc1 next-20200413]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the
Daniel Vetter, Ville, any thoughts about this?
Thanks,
Simon
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Monday, April 13, 2020 11:40 PM, Yussuf Khalil wrote:
> DRM now has a globally available "RGB quantization range" connector
> property. i915's "Broadcast RGB" that fulfils the same purpose is now
> considered deprecated, so drop it in favor of the DRM property.
For a UAPI point-of-view, I'm n
Can you also add docs for this property in "DOC: standard connector
properties" in drm_connector.c?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Ensure RGB quantization range changes are applied immediately.
Signed-off-by: Yussuf Khalil
---
drivers/gpu/drm/drm_atomic_helper.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 85d163f16801..b74e90a2b21
Add a new flag to mark modes that are considered a CE mode according to the
CEA-861 specification. Modes without this flag are implicitly considered to
be IT modes.
User-space applications may use this flag to determine possible
implications of using a CE mode (e.g., limited RGB range).
There is
This helper can be used to determine the appropriate RGB quantization range
based on a connector's "RGB quantization range" property and a mode.
Signed-off-by: Yussuf Khalil
---
drivers/gpu/drm/drm_connector.c | 31 +++
include/drm/drm_connector.h | 4
2 fil
Add a new "RGB quantization range" property with three possible values:
Automatic, Limited, and Full. User-space may use this property to override
the automatic selection of the RGB range as specified by CTA-861. Drivers
should attach this property to all CTA-861 sinks.
Signed-off-by: Yussuf Khali
DRM now has a globally available "RGB quantization range" connector
property. i915's "Broadcast RGB" that fulfils the same purpose is now
considered deprecated, so drop it in favor of the DRM property.
Signed-off-by: Yussuf Khalil
---
drivers/gpu/drm/i915/display/intel_atomic.c | 8
.../
The CTA-861 specification differentiates between IT and CE modes. For the
latter, it requires sources to send "limited RGB quantization range", i.e.,
allowed RGB values are constrained to 16 - 235 (in the 8 bit case). A sink may
indicate support for full range RGB (0 - 255) in CE modes through its
https://bugzilla.kernel.org/show_bug.cgi?id=206021
--- Comment #7 from Clément Guérin (li...@protonmail.com) ---
No improvement on 5.7-rc1
--
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-
Hello,
On Mon, Apr 13, 2020 at 05:40:32PM -0400, Kenny Ho wrote:
> By lack of consense, do you mean Intel's assertion that a standard is
> not a standard until Intel implements it? (That was in the context of
> OpenCL language standard with the concept of SubDevice.) I thought
> the discussion so
Looks like I accidentally made it so you couldn't force DPCD backlight
support on, whoops. Fix that.
Signed-off-by: Lyude Paul
Fixes: 17f5d57915be ("drm/i915: Force DPCD backlight mode on X1 Extreme 2nd Gen
4K AMOLED panel")
Cc: Adam Jackson
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: "Ville Syrj
Hi,
On Mon, Apr 13, 2020 at 4:54 PM Tejun Heo wrote:
>
> Allocations definitely are acceptable and it's not a pre-requisite to have
> work-conserving control first either. Here, given the lack of consensus in
> terms of what even constitute resource units, I don't think it'd be a good
> idea to c
Hi Tejun
>
> And, thanks a lot for the vblank explanation. I really enjoyed readin it. :)
You were not the only one who liked it :-)
We ended up with an updated explanation in drm_vblank.c:
https://cgit.freedesktop.org/drm/drm-misc/tree/drivers/gpu/drm/drm_vblank.c
Including some nice ascii ar
Hello,
On Mon, Apr 13, 2020 at 04:17:14PM -0400, Kenny Ho wrote:
> Perhaps we can even narrow things down to just
> gpu.weight/gpu.compute.weight as a start? In this aspect, is the key
That sounds great to me.
> objection to the current implementation of gpu.compute.weight the
> work-conserving
Hello,
On Mon, Apr 13, 2020 at 04:18:57PM -0400, Lyude Paul wrote:
> Hi Tejun! Sorry to bother you, but have you had a chance to look at any of
> this yet? Would like to continue moving this forward
Sorry, wasn't following this thread. Have you looked at kthread_worker?
https://git.kernel.org/
Hi Tejun! Sorry to bother you, but have you had a chance to look at any of
this yet? Would like to continue moving this forward
On Fri, 2020-03-27 at 16:38 -0400, Lyude Paul wrote:
> Oops, completely forgot to link to the work_struct version of this patch:
>
> [1]
> https://gitlab.freedesktop.or
(replying again in plain-text)
Hi Tejun,
Thanks for taking the time to reply.
Perhaps we can even narrow things down to just
gpu.weight/gpu.compute.weight as a start? In this aspect, is the key
objection to the current implementation of gpu.compute.weight the
work-conserving bit? This work-con
[AMD Official Use Only - Internal Distribution Only]
Hi Tejun,
Thanks for taking the time to reply.
Perhaps we can even narrow things down to just gpu.weight/gpu.compute.weight as
a start? In this aspect, is the key objection to the current implementation of
gpu.compute.weight the work-conser
Hello, Kenny.
On Tue, Mar 24, 2020 at 02:49:27PM -0400, Kenny Ho wrote:
> Can you elaborate more on what are the missing pieces?
Sorry about the long delay, but I think we've been going in circles for quite
a while now. Let's try to make it really simple as the first step. How about
something lik
Hi Laurent.
> > Some rambling below you can ignore.
>
> I tend not to split trivial cleanups like these in separate patches,
> should I ?
See my comment above, in other words no need to split.
Sam
___
dri-devel mailing list
dri-devel@lists.fre
On Mon, 2020-04-13 at 22:32 +0800, Jason Yan wrote:
> Fix the following coccicheck warning:
>
> drivers/gpu/drm/i915/gvt/vgpu.c:127:30-31: WARNING: Use ARRAY_SIZE
>
> Signed-off-by: Jason Yan
> ---
> drivers/gpu/drm/i915/gvt/vgpu.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> di
On Mon, Apr 13, 2020 at 1:47 PM Paul Menzel wrote:
>
> Dear Prike, dear Alex, dear Linux folks,
>
>
> Am 13.04.20 um 10:44 schrieb Paul Menzel:
>
> > A regression between causes a system with the AMD board MSI B350M MORTAR
> > (MS-7A37) with an AMD Ryzen 3 2200G not to power off any more but just
Hi Sam,
On Mon, Apr 13, 2020 at 07:43:52AM +0200, Sam Ravnborg wrote:
> On Thu, Apr 09, 2020 at 03:36:36AM +0300, Laurent Pinchart wrote:
> > Make the connector creation optional to enable usage of the
> > simple-bridge with the DRM bridge connector helper.
> >
> > Signed-off-by: Laurent Pinchart
Hi Sam,
On Mon, Apr 13, 2020 at 07:33:25AM +0200, Sam Ravnborg wrote:
> On Thu, Apr 09, 2020 at 03:36:35AM +0300, Laurent Pinchart wrote:
> > Instead of poking into the DT node of the next bridge for its DDC bus
> > and implementing the .get_modes() and .detect() connector operations
> > manually,
Applied. thanks!
Alex
On Fri, Apr 10, 2020 at 7:46 AM Colin King wrote:
>
> From: Colin Ian King
>
> The variable dp_ref_clk_khz is being initialized with a value that is
> never read and it is being updated later with a new value. The
> initialization is redundant and can be removed.
>
> Add
On 13/04/2020 15:31, Clément Péron wrote:
Hi,
On Mon, 13 Apr 2020 at 16:18, Clément Péron wrote:
Hi Steven,
On Mon, 13 Apr 2020 at 15:18, Steven Price wrote:
On 11/04/2020 21:06, Clément Péron wrote:
OPP table can defined both frequency and voltage.
Register the mali regulator if it exi
Can you make sure this lands in drm-misc?
Thanks,
Alex
On Fri, Apr 10, 2020 at 8:15 AM Koenig, Christian
wrote:
>
>
>
> Am 10.04.2020 12:58 schrieb "Pan, Xinhui" :
>
> The delayed delete list is per device which might be very huge. And in
> a heavy workload test, the list might always not be em
Applied. thanks!
Alex
On Mon, Apr 13, 2020 at 10:06 AM Jason Yan wrote:
>
> Fix the following gcc warning:
>
> drivers/gpu/drm/radeon/ci_dpm.c:82:36: warning: ‘defaults_saturn_pro’
> defined but not used [-Wunused-const-variable=]
> static const struct ci_pt_defaults defaults_saturn_pro =
>
Applied. thanks!
Alex
On Mon, Apr 13, 2020 at 10:06 AM Jason Yan wrote:
>
> Fix the following gcc warning:
>
> drivers/gpu/drm/radeon/si_dpm.c:255:33: warning: ‘dte_data_tahiti_le’
> defined but not used [-Wunused-const-variable=]
> static const struct si_dte_data dte_data_tahiti_le =
>
> Repo
Applied. Thanks!
On Mon, Apr 13, 2020 at 10:06 AM Jason Yan wrote:
>
> This code is dead, let's remove it.
>
> Reported-by: Hulk Robot
> Signed-off-by: Jason Yan
> ---
> drivers/gpu/drm/amd/amdgpu/si_dpm.c | 20
> 1 file changed, 20 deletions(-)
>
> diff --git a/drivers/g
On Wed, Apr 8, 2020 at 9:42 PM Aurabindo Pillai wrote:
>
> Changes in v2
>
> * Add dev_fmt format prefix
> * Removed hardcoded module names in pr_* and dev_* prints
>
> Aurabindo Pillai (3):
> drm/amd/amdgpu: add prefix for pr_* prints
> drm/amd/amdgpu: add print prefix for dev_* variants
>
On Mon, Apr 13, 2020 at 5:29 AM Jason Yan wrote:
>
> Fix the following gcc warning:
>
> drivers/gpu/drm/amd/amdgpu/../display/dc/dce80/dce80_hw_sequencer.c:43:46:
> warning: ‘reg_offsets’ defined but not used [-Wunused-const-variable=]
> static const struct dce80_hw_seq_reg_offsets reg_offsets[]
On Mon, Apr 13, 2020 at 6:11 PM Chen-Yu Tsai wrote:
>
> On Mon, Apr 13, 2020 at 5:55 PM Jernej Skrabec
> wrote:
> >
> > m divider in DDC clock register is 4 bits wide. Fix that.
> >
> > Fixes: 9c5681011a0c ("drm/sun4i: Add HDMI support")
> > Signed-off-by: Jernej Skrabec
>
> Reviewed-by: Chen-Y
On Mon, Apr 13, 2020 at 5:29 AM Tang Bin wrote:
>
> The struct drm_dp_desc contains struct drm_dp_dpcd_ident, and the struct
> drm_dp_dpcd_ident contains the array, so zero-initialization requires a
> more couple of braces. In the ARM compiler environment, the compile
> warning pointing it out:
>
On 11/04/2020 21:06, Clément Péron wrote:
OPP table can defined both frequency and voltage.
Register the mali regulator if it exist.
Signed-off-by: Clément Péron
---
drivers/gpu/drm/panfrost/panfrost_devfreq.c | 34 ++---
drivers/gpu/drm/panfrost/panfrost_device.h | 1 +
On 11/04/2020 21:06, Clément Péron wrote:
In case of failure we need to remove OPP table.
Use Linux classic error handling with goto usage.
Signed-off-by: Clément Péron
Reviewed-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_devfreq.c | 16
1 file changed, 12 i
[AMD Official Use Only - Internal Distribution Only]
You can add a Reviewed-By and Tested-By for me on this patch, unless you want
me to send it out instead, then you can review it.
Kent
> -Original Message-
> From: amd-gfx On Behalf Of
> Christian König
> Sent: Saturday, April 11, 2
On Mon, Apr 13, 2020 at 5:55 PM Jernej Skrabec wrote:
>
> m divider in DDC clock register is 4 bits wide. Fix that.
>
> Fixes: 9c5681011a0c ("drm/sun4i: Add HDMI support")
> Signed-off-by: Jernej Skrabec
Reviewed-by: Chen-Yu Tsai
___
dri-devel mailing
On Thu, 9 Apr 2020 at 08:43, John Stultz wrote:
>
> Daniel noted[1] that commit d606dc9a6323 ("drm: kirin: Add
> register connect helper functions in drm init") was unnecessary
> and incorrect, as drm_dev_register does register connectors for
> us.
>
> Thus, this patch reverts the change as sugges
While booting stable-rc 4.14 branch kernel this warning was noticed on
Qualcomm APQ 8016 SBC (DT) Dragonboard 410c device.
[8.459580] clk: failed to reparent byte0_clk_src to dsi0pllbyte: -22
[8.459724] clk: failed to reparent pclk0_clk_src to dsi0pll: -22
[8.466474] msm 1a0.mdss:
Fix the following gcc warning:
drivers/gpu/drm/amd/amdgpu/../display/dc/dce80/dce80_hw_sequencer.c:43:46:
warning: ‘reg_offsets’ defined but not used [-Wunused-const-variable=]
static const struct dce80_hw_seq_reg_offsets reg_offsets[] = {
^~~
Some processes, such as systemd, are only polling for EPOLLERR|EPOLLHUP.
As drm_file uses unkeyed wakeups, such a poll receives many spurious
wakeups from uninteresting events.
Use keyed wakeups to allow the wakeup target to more efficiently discard
these uninteresting events.
Signed-off-by: Kenn
Duplicated 'we'
Signed-off-by: Christophe JAILLET
---
drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
index 998bef1190a3..b5fed67c4651 100644
-
> > ADV7511 support sample rates up to 192kHz. CTS and N parameters should
> > be computed accordingly so this commit extend the list up to maximum
> > supported sample rate.
> >
> > Signed-off-by: Bogdan Togorean
> > ---
> > drivers/gpu/drm/bridge/adv7511/adv7511_audio.c | 12
> > 1
Commit f5a98bfe7b37 ("dt-bindings: display: Convert Allwinner display
pipeline to schemas") replaced sunxi/sun4i-drm.txt with
allwinner,sun*.yaml files in Documentation/devicetree/bindings/display/,
but did not adjust DRM DRIVERS FOR ALLWINNER A10.
Since then, ./scripts/get_maintainer.pl --self-te
The GPU can be one of the big heat sources on a SoC. Allow the
"#cooling-cells" property to be specified for ARM Mali Utgard GPUs so
the GPU clock speeds (and voltages) can be reduced to prevent a SoC from
overheating.
Reviewed-by: Qiang Yu
Signed-off-by: Martin Blumenstingl
---
Changes since v4
Message logged by 'dev_xxx()' or 'pr_xxx()' should end with a '\n'.
While at it, split some long lines that where not that far.
Signed-off-by: Christophe JAILLET
---
Most of them have been added in commit bd607166af7f ("drm/amdgpu: Enable
reading FRU chip via I2C v3")
---
drivers/gpu/drm/amd/a
In case of failure we need to remove OPP table.
Use Linux classic error handling with goto usage.
Signed-off-by: Clément Péron
---
drivers/gpu/drm/panfrost/panfrost_devfreq.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_
The struct drm_dp_desc contains struct drm_dp_dpcd_ident, and the struct
drm_dp_dpcd_ident contains the array, so zero-initialization requires a
more couple of braces. In the ARM compiler environment, the compile
warning pointing it out:
drivers/gpu/drm/drm_dp_mst_topology.c: In function
'dr
OPP table can defined both frequency and voltage.
Register the mali regulator if it exist.
Signed-off-by: Clément Péron
---
drivers/gpu/drm/panfrost/panfrost_devfreq.c | 34 ++---
drivers/gpu/drm/panfrost/panfrost_device.h | 1 +
2 files changed, 31 insertions(+), 4 deletions(
59 matches
Mail list logo
