For layer_split no need user to enable/disable it, but compute it in
komeda internally, komeda will enable it if the scaling exceed the
acceptable range of scaler.
Signed-off-by: james qian wang (Arm Technology China)
---
drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h | 3 ++-
.../drm/ar
Enable image enhancer when the input data flow is 2x+ upscaling.
Signed-off-by: james qian wang (Arm Technology China)
---
drivers/gpu/drm/arm/display/komeda/komeda_kms.h| 7 ++-
drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c | 4
drivers/gpu/drm/arm/display/kome
On Wed, Jul 03, 2019 at 03:02:08PM -0700, Christoph Hellwig wrote:
> Hi Jérôme, Ben and Jason,
>
> below is a series against the hmm tree which fixes up the mmap_sem
> locking in nouveau and while at it also removes leftover legacy HMM APIs
> only used by nouveau.
As much as I like this series, i
---
drivers/gpu/drm/drm_agpsupport.c | 43
include/drm/drm_agpsupport.h | 14 -
2 files changed, 57 deletions(-)
diff --git a/drivers/gpu/drm/drm_agpsupport.c b/drivers/gpu/drm/drm_agpsupport.c
index 117b8ee98243..8b4e7b1d82e4 100644
--- a/
Each iteration of for_each_available_child_of_node puts the previous
node, but in the case of a break from the middle of the loop there is
no put, thus causing a memory leak. Hence add an of_node_put before the
break.
Issue found with Coccinelle.
Signed-off-by: Nishka Dasgupta
---
drivers/gpu/dr
Each iteration of for_each_child_of_node puts the previous
node, but in the case of a goto from the middle of the loop, there is
no put, thus causing a memory leak. Hence add an of_node_put before the
goto in two places.
Issue found with Coccinelle.
Signed-off-by: Nishka Dasgupta
---
drivers/gpu
On Friday, 5 July 2019, Marek Olšák wrote:
> On Fri, Jul 5, 2019 at 5:27 AM Timur Kristóf
> wrote:
>
> > On Wed, 2019-07-03 at 14:44 -0400, Marek Olšák wrote:
> > > You can run:
> > > AMD_DEBUG=testdmaperf glxgears
> > >
> > > It tests transfer sizes of up to 128 MB, and it tests ~60 slightly
>
17.06.2019 17:51, Maxime Ripard пишет:
> From: Maxime Ripard
>
> Rewrite the command line parser in order to get away from the state machine
> parsing the video mode lines.
>
> Hopefully, this will allow to extend it more easily to support named modes
> and / or properties set directly on the co
On Fri, Jul 05, 2019 at 02:25:46PM +0200, Daniel Vetter wrote:
> On Fri, Jul 05, 2019 at 11:44:45AM +, james qian wang (Arm Technology
> China) wrote:
> > For layer_split:
> > Enable it if the scaling exceed the accept range of scaler.
> >
> > For image_enhancer:
> > Enable it if the scaling i
https://bugs.freedesktop.org/show_bug.cgi?id=102322
--- Comment #83 from Wilko Bartels ---
(In reply to Jaap Buurman from comment #81)
> issue seems to be using a setup that requires higher engine clocks in idle
> AFAIK. Either high refresh displays, or in my case, multiple monitors. Could
> this
Hi Jacopo,
On Sat, Jul 6, 2019 at 4:07 PM Jacopo Mondi wrote:
> Add device tree bindings documentation for the Renesas R-Car Display
> Unit Color Management Module.
>
> CMM is the image enhancement module available on each R-Car DU video
> channel on R-Car Gen2 and Gen3 SoCs (V3H and V3M excluded
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 fixed:
Reviewed-by: Sam Ravnborg
You could also consider to add a few words in the
https://bugs.freedesktop.org/show_bug.cgi?id=110514
--- Comment #25 from CI Bug Log ---
The CI Bug Log issue associated to this bug has been archived.
New failures matching the above filters will not be associated to this bug
anymore.
--
You are receiving this mail because:
You are the assigne
On Mon, Jul 08, 2019 at 03:20:44AM +, bugzilla-dae...@freedesktop.org wrote:
> How is this not a graphics driver bug?
He meant it could be a game engine bug (network or 3D, very probably).
You are both right.
CSGO 3D engine on based linux OSes is really bad if you use maps which are not
in t
https://bugs.freedesktop.org/show_bug.cgi?id=111082
--- Comment #3 from Sylvain BERTRAND ---
On Mon, Jul 08, 2019 at 03:20:44AM +, bugzilla-dae...@freedesktop.org
wrote:
> How is this not a graphics driver bug?
He meant it could be a game engine bug (network or 3D, very probably).
You are b
On Fri, 5 Jul 2019 06:16:37 +0530
Ramalingam C wrote:
> This patch adds a DRM ENUM property to the selected connectors.
> This property is used for mentioning the protected content's type
> from userspace to kernel HDCP authentication.
>
> Type of the stream is decided by the protected content
On Mon, 8 Jul 2019 12:52:17 +0300
Pekka Paalanen wrote:
> On Fri, 5 Jul 2019 06:16:37 +0530
> Ramalingam C wrote:
>
> > This patch adds a DRM ENUM property to the selected connectors.
> > This property is used for mentioning the protected content's type
> > from userspace to kernel HDCP authen
On Fri, 5 Jul 2019 06:16:40 +0530
Ramalingam C wrote:
> drm function is defined and exported to update a connector's
> content protection property state and to generate a uevent along
> with it.
>
> Need ACK for the uevent from userspace consumer.
>
> v2:
> Update only when state is differen
On Fri, 5 Jul 2019 06:16:42 +0530
Ramalingam C wrote:
> In the kernel documentation, HDCP specifications links are shared as a
> reference for SRM table format.
>
> Signed-off-by: Ramalingam C
> ---
> drivers/gpu/drm/drm_hdcp.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/
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/
https://patchwork.kernel.org
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: Jean-
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 insertions(
Add DT binding for led-backlight.
Signed-off-by: Jean-Jacques Hiblot
---
.../bindings/leds/backlight/led-backlight.txt | 29 +++
1 file changed, 29 insertions(+)
create mode 100644
Documentation/devicetree/bindings/leds/backlight/led-backlight.txt
diff --git a/Documentation/de
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
---
This would give us a WARN_ON() if the pin/unpin calls are unbalanced.
Proposed-by: Laurent Pinchart
Signed-off-by: Jean-Jacques Hiblot
---
drivers/gpu/drm/omapdrm/omap_gem.c | 45 +++---
1 file changed, 23 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/omap
From: Tomi Valkeinen
omap_gem_new() has a comment about OMAP_BO_SCANOUT which does not make
sense. Also, for the TILER case, we drop OMAP_BO_SCANOUT flag for some
reason.
It's not clear what the original purpose of OMAP_BO_SCANOUT is, but
presuming it means "scanout buffer, something that can be
From: Tomi Valkeinen
Allow NULL to be passed in 'dma_addr' for omap_gem_pin(), in case the
caller does not need the dma_addr.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/omap_gem.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/o
A first version of this work had been sent by Tomi Valkeinen in may 2017
(https://www.spinics.net/lists/dri-devel/msg140663.html).
This series adds a few new OMAP_BO flags to help the userspace manage
situations where it needs to use lots of buffers, and would currently run
out of TILER space. Th
From: Tomi Valkeinen
Add a helper function omap_gem_validate_flags() which validates the
omap_bo flags passed from the userspace.
Also drop the dev_err() message, as the userspace can cause that at
will.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/omap_gem.c | 40 +++
From: Tomi Valkeinen
On SoCs with DMM/TILER, we have two ways to allocate buffers: normal
dma_alloc or via DMM (which basically functions as an IOMMU). DMM can
map 128MB at a time, and we only map the DMM buffers when they are used
(i.e. not at alloc time). If DMM is present, omapdrm always uses
From: Tomi Valkeinen
Reorder OMAP_BO flags and improve the comments.
Signed-off-by: Tomi Valkeinen
---
include/uapi/drm/omap_drm.h | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/include/uapi/drm/omap_drm.h b/include/uapi/drm/omap_drm.h
index 1fccffef9e27.
From: Tomi Valkeinen
Add omap_gem_unpin_locked() which is a version of omap_gem_unpin() that
expects the caller to hold the omap_obj lock.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/omap_gem.c | 24 +---
1 file changed, 17 insertions(+), 7 deletions(-)
diff
From: Tomi Valkeinen
OMAP_BO_TILED does not make sense, as OMAP_BO_TILED_* values are not
bitmasks but normal values. As we already have OMAP_BO_TILED_MASK for
the mask, we can remove OMAP_BO_TILED and use OMAP_BO_TILED_MASK
instead.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/om
On Mon, Jul 08, 2019 at 12:26:59PM +0200, Jean-Jacques Hiblot wrote:
> Add DT binding for led-backlight.
>
> Signed-off-by: Jean-Jacques Hiblot
> ---
> .../bindings/leds/backlight/led-backlight.txt | 29 +++
> 1 file changed, 29 insertions(+)
> create mode 100644
> Documentatio
This file isn't using any interfaces from so
just drop the include.
Signed-off-by: Linus Walleij
---
drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c
b/drivers/gpu/drm/bridge/meg
This driver uses exclusively the new GPIO API from
so just drop the old API headers.
Signed-off-by: Linus Walleij
---
drivers/gpu/drm/bridge/nxp-ptn3460.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/bridge/nxp-ptn3460.c
b/drivers/gpu/drm/bridge/nxp-ptn3460.c
index 9fd2
This driver uses the new GPIO API from
so drop the inclusion of the legacy header.
Signed-off-by: Linus Walleij
---
drivers/gpu/drm/bridge/parade-ps8622.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/parade-ps8622.c
b/drivers/gpu/drm/bridge/parade-ps8622.c
index 69
https://bugs.freedesktop.org/show_bug.cgi?id=111087
Bug ID: 111087
Summary: SteamOS fails to boot with "drmmode_do_crtc_dpms
cannot get last vblank counter"
Product: DRI
Version: XOrg git
Hardware: Other
OS:
https://bugs.freedesktop.org/show_bug.cgi?id=111087
--- Comment #1 from Ludovico de Nittis ---
Created attachment 144720
--> https://bugs.freedesktop.org/attachment.cgi?id=144720&action=edit
Xorg.0.log
--
You are receiving this mail because:
You are the assignee for the bug.__
https://bugs.freedesktop.org/show_bug.cgi?id=111087
--- Comment #2 from Ludovico de Nittis ---
Created attachment 144721
--> https://bugs.freedesktop.org/attachment.cgi?id=144721&action=edit
modinfo.amdgpu.log
--
You are receiving this mail because:
You are the assignee for the bug.__
https://bugs.freedesktop.org/show_bug.cgi?id=111087
--- Comment #3 from Ludovico de Nittis ---
Created attachment 144722
--> https://bugs.freedesktop.org/attachment.cgi?id=144722&action=edit
lspci.vnn.log
--
You are receiving this mail because:
You are the assignee for the bug.___
https://bugs.freedesktop.org/show_bug.cgi?id=111087
--- Comment #4 from Ludovico de Nittis ---
Created attachment 144723
--> https://bugs.freedesktop.org/attachment.cgi?id=144723&action=edit
dmesg.log
--
You are receiving this mail because:
You are the assignee for the bug.___
https://bugs.freedesktop.org/show_bug.cgi?id=111087
--- Comment #5 from Ludovico de Nittis ---
Created attachment 144724
--> https://bugs.freedesktop.org/attachment.cgi?id=144724&action=edit
dkms.status.log
--
You are receiving this mail because:
You are the assignee for the bug._
https://bugs.freedesktop.org/show_bug.cgi?id=111087
--- Comment #6 from Ludovico de Nittis ---
Created attachment 144725
--> https://bugs.freedesktop.org/attachment.cgi?id=144725&action=edit
lsmod.amdgpu.log
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=111087
--- Comment #7 from Ludovico de Nittis ---
Created attachment 144726
--> https://bugs.freedesktop.org/attachment.cgi?id=144726&action=edit
package.log
--
You are receiving this mail because:
You are the assignee for the bug._
https://bugs.freedesktop.org/show_bug.cgi?id=110674
--- Comment #46 from Tom B ---
Has anyone tested 5.3 yet? I noticed there are a lot of powerplay changes.
Since this bug messes up the card's power profile, how safe is testing new
kernels? Is there any danger of my card being damaged due to wr
This way the backlight can be referenced through its device node and
enabling/disabling can be managed through the panel driver.
Signed-off-by: Lucas Stach
---
drivers/video/backlight/rave-sp-backlight.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/video
From: Ville Syrjälä
The end of the series is just a reposting of the fp16 stuff for gen4+.
The start of the series is new stuff to allow planes to dictate the
minimum cdclk, which is sometimes needed for downscaling or fp16
(and sometimes even for other pixel formats). Thanks to that new code
the
From: Ville Syrjälä
Add a small wrapper around lockdep_assert_held() to make
it a bit more conventinet to use with modeset locks.
Signed-off-by: Ville Syrjälä
---
include/drm/drm_modeset_lock.h | 9 +
1 file changed, 9 insertions(+)
diff --git a/include/drm/drm_modeset_lock.h b/includ
From: Ville Syrjälä
Allow drivers to call drm_atomic_helper_check_modeset() without
having the crtc helper funcs specified. i915 doesn't need those
anymore.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_atomic_helper.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/
From: Ville Syrjälä
i915 doesn't use the crtc_state->plane_changed flag for anything,
so setting it is pointless.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_atomic.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c
From: Ville Syrjälä
There's a helper in drm_fourcc.h these days to check of we're dealing
with a two plane YUV format. Make use if it.
Also s/plane/color_plane/ in skl_plane_relative_data_rate() to reduce
the confusion.
Signed-off-by: Ville Syrjälä
---
.../gpu/drm/i915/display/intel_atomic_pl
From: Ville Syrjälä
Bspec says that glk+ max downscale factor is <3.0 for all pixel formats.
Older platforms had a max of <2.0 for NV12. Update the code to deal with
this.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 9 ++---
1 file changed, 6 insertions(
From: Ville Syrjälä
Clean up the mess with the drm vs. intel types in
intel_crtc_atomic_check() and rename varibles accordingly.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 54 ++--
1 file changed, 26 insertions(+), 28 deletions(-)
diff --gi
From: Ville Syrjälä
Exfiltrate the cdclk code from intel_modeset_checks() into
intel_modeset_calc_cdclk().
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_cdclk.c | 135 ++-
drivers/gpu/drm/i915/display/intel_cdclk.h | 6 +-
drivers/gpu/drm/i915/displa
From: Ville Syrjälä
So far we've sort of protected the global state under dev_priv with
the connection_mutex. I wan to change that so that we can change the
cdclk even for pure plane updates. To that end let's formalize the
protection of the global state to follow what I started with the cdclk
co
From: Ville Syrjälä
While not all platforms allow us to change the cdclk frequency
we should still verify that the fixed cdclk frequency isn't
too low. To that end let's cook up a .modeset_calc_cdclk()
implementation that only does the min_cdclk vs. actual cdclk
frequency check for such platforms
From: Ville Syrjälä
We need to insert stuff between the plane and crtc .atomic_check()
drm_atomic_helper_check_planes() doesn't allow us to do that so
stop using it and hand roll the loops instead.
Signed-off-by: Ville Syrjälä
---
.../gpu/drm/i915/display/intel_atomic_plane.c | 10 +---
.../gp
From: Ville Syrjälä
Various pixel formats and plane scaling impose additional constraints
on the cdclk frequency. Provide a new plane->min_cdclk() hook that
will be used to compute the minimum acceptable cdclk frequency for
each plane.
Annoyingly on some platforms the numer of active planes affe
From: Ville Syrjälä
The normal cdclk handling now takes care of making sure the
plane's pixel rate doesn't exceed the spec appointed percentage
of the cdclk frequency. Thus we can nuke
skl_check_pipe_max_pixel_rate().
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.
From: Ville Syrjälä
check_digital_port_conflicts() is done needlessly late. Move it earlier.
This will be needed as later on we want to set any_ms=true a bit later
for non-modesets too and we can't call this guy without the
connection_mutex held.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/dr
From: Ville Syrjälä
To make the logs a bit less confusing let's toss in some
debug prints to indicate whether the cdclk reprogramming
is going to happen with a single pipe active or whether we
need to turn all pipes off for the duration.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/di
From: Ville Syrjälä
Now that the planes declare their minimum cdclk requirements properly
we don't need to check the cdclk in skl_max_scale() anymore. Just check
against the maximum downscale ratio, and move the code next to it's
only caller.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i9
From: Ville Syrjälä
skl+ supports fp16 pixel formats on all universal planes. Add the
necessary bits to expose that capability. The main different to
icl is that we can't scale fp16, so need to add the relevant
checks.
v2: Rebase on top of icl fp16
Split skl+ bits into a separate patch
Revi
From: Ville Syrjälä
gen4+ supports fp16 pixel formats on the primary planes. Add the
relevant code.
On ivb fp16 scanout is slightly busted. The output from the plane will
have 1/4 the expected value. For the primary plane we would have to
use the pipe gamma or pipe csc to correct that which woul
From: Ville Syrjälä
ivb+ supports fp16 pixel formats on the sprite planes planes. Expose
that capability.
On ivb/hsw fp16 scanout is slightly busted. The output from the plane
will have 1/4 the expected value. For the sprite plane we can fix that
up with the plane gamma unit. This was fixed on b
From: Ville Syrjälä
snb supports fp16 pixel formats on the sprite planes. Expose that
capability. Nothing special needs to be done, it just works.
v2: Rebase on top of icl fp16
Split snb+ sprite bits into a separate patch
Reviewed-by: Maarten Lankhorst
Signed-off-by: Ville Syrjälä
---
dr
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:
> > > Store width and height of the bo. Needed in case userspace
> > > sets up a framebuf
Compile-testing this driver on a NOMMU configuration shows a link failure:
drivers/gpu/drm/exynos/exynos_drm_gem.o: In function `exynos_drm_gem_fault':
exynos_drm_gem.c:(.text+0x484): undefined reference to `vmf_insert_mixed'
Add a CONFIG_MMU dependency to ensure we only enable this in configurat
'struct hmm_mirror' is not defined without the Kconfig option set,
so we cannot include it within another struct:
In file included from drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgpu.h:72:
drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgpu_mn.h:69:20: error: field has
incomplete type 'struct hmm_mirror'
On 32-bit architectures, dividing a 64-bit integer in the kernel
leads to a link error:
ERROR: "__udivdi3" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
ERROR: "__divdi3" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
Change the two recently introduced instances to a multiply+shift
operati
Without this header, we get a compiler error in some configurations:
.../dc/dcn20/dcn20_hwseq.c: In function 'dcn20_hwss_wait_for_blank_complete':
.../dc/dcn20/dcn20_hwseq.c:1493:3: error: implicit declaration of function
'udelay' [-Werror=implicit-function-declaration]
Note: the use of udelay i
A couple of calls to smu_get_current_clk_freq() and smu_force_clk_levels()
pass constants of the wrong type, leading to warnings with clang-8:
drivers/gpu/drm/amd/amdgpu/../powerplay/vega20_ppt.c:995:39: error: implicit
conversion from enumeration type 'PPCLK_e' to different enumeration type 'enu
A mistake in the error handling caused an uninitialized
variable to be used:
drivers/gpu/drm/amd/amdgpu/../powerplay/smu_v11_0.c:1102:10: error: variable
'freq' is used uninitialized whenever '?:' condition is false
[-Werror,-Wsometimes-uninitialized]
ret = smu_get_current_clk_f
If smu_get_current_rpm() fails, we can't use the output,
as that may be uninitialized:
drivers/gpu/drm/amd/amdgpu/../powerplay/vega20_ppt.c:3023:8: error: variable
'current_rpm' is used uninitialized whenever '?:' condition is false
[-Werror,-Wsometimes-uninitialized]
ret = smu_get_curre
On 7/8/19 2:46 PM, Arnd Bergmann wrote:
> Compile-testing this driver on a NOMMU configuration shows a link failure:
>
> drivers/gpu/drm/exynos/exynos_drm_gem.o: In function `exynos_drm_gem_fault':
> exynos_drm_gem.c:(.text+0x484): undefined reference to `vmf_insert_mixed'
>
> Add a CONFIG_MMU de
The navi10_ppt code contains two instances of an incorrect struct initializer:
drivers/gpu/drm/amd/amdgpu/../powerplay/navi10_ppt.c:601:33: error: suggest
braces around initialization of subobject
[-Werror,-Wmissing-braces]
static SmuMetrics_t metrics = {0};
On 7/8/19 9:52 AM, Arnd Bergmann wrote:
> On 32-bit architectures, dividing a 64-bit integer in the kernel
> leads to a link error:
>
> ERROR: "__udivdi3" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
> ERROR: "__divdi3" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
>
> Change the two rec
https://bugs.freedesktop.org/show_bug.cgi?id=111087
Michel Dänzer changed:
What|Removed |Added
Attachment #144721|text/x-log |text/plain
mime type|
https://bugs.freedesktop.org/show_bug.cgi?id=111087
Michel Dänzer changed:
What|Removed |Added
Attachment #144720|text/x-log |text/plain
mime type|
https://bugs.freedesktop.org/show_bug.cgi?id=111087
Michel Dänzer changed:
What|Removed |Added
Attachment #144723|text/x-log |text/plain
mime type|
https://bugs.freedesktop.org/show_bug.cgi?id=111087
Michel Dänzer changed:
What|Removed |Added
Attachment #144722|text/x-log |text/plain
mime type|
https://bugs.freedesktop.org/show_bug.cgi?id=111087
Michel Dänzer changed:
What|Removed |Added
Attachment #144726|text/x-log |text/plain
mime type|
https://bugs.freedesktop.org/show_bug.cgi?id=111087
Michel Dänzer changed:
What|Removed |Added
Attachment #144724|text/x-log |text/plain
mime type|
https://bugs.freedesktop.org/show_bug.cgi?id=111087
Michel Dänzer changed:
What|Removed |Added
Attachment #144725|text/x-log |text/plain
mime type|
https://bugs.freedesktop.org/show_bug.cgi?id=111087
Michel Dänzer changed:
What|Removed |Added
Summary|SteamOS fails to boot with |SteamOS boots to black
https://bugs.freedesktop.org/show_bug.cgi?id=111089
Bug ID: 111089
Summary: Multiple calls to ddcutil cause hard process hangs
from within the DRM/i2c system
Product: DRI
Version: XOrg git
Hardware: x86-64 (AMD64)
When CONFIG_PERF_EVENTS is disabled, we cannot compile the pmu
portion of the amdgpu driver:
drivers/gpu/drm/amd/amdgpu/amdgpu_pmu.c:48:38: error: no member named 'hw' in
'struct perf_event'
struct hw_perf_event *hwc = &event->hw;
~ ^
drivers/gpu/
Enabling amdgpu but not CONFIG_DRM_AMD_DC leads to a warning:
drivers/gpu/drm/amd/amdgpu/nv.c: In function 'nv_set_ip_blocks':
drivers/gpu/drm/amd/amdgpu/nv.c:400:3: error: #warning "Enable
CONFIG_DRM_AMD_DC for display support on navi." [-Werror=cpp]
# warning "Enable CONFIG_DRM_AMD_DC for disp
On Mon, Jul 8, 2019 at 10:42 AM Arnd Bergmann wrote:
>
> Enabling amdgpu but not CONFIG_DRM_AMD_DC leads to a warning:
>
> drivers/gpu/drm/amd/amdgpu/nv.c: In function 'nv_set_ip_blocks':
> drivers/gpu/drm/amd/amdgpu/nv.c:400:3: error: #warning "Enable
> CONFIG_DRM_AMD_DC for display support on n
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 parallel RGB input mode.
Changes since v1:
* Device-tree bindings in one file
* D/C GPIO pin i
Add driver for Ilitek ILI9341 panels in parallel RGB mode
Signed-off-by: Josef Lusticky
---
MAINTAINERS | 6 +
drivers/gpu/drm/panel/Kconfig| 9 +
drivers/gpu/drm/panel/Makefile | 1 +
drivers/gpu/drm/panel/panel-ilitek-ili9341
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 ---
1 file changed, 56 insertions(+), 11 deletions(-)
diff --git a/Documenta
Creating the msm gem address space requires a reference to the dev where
the iommu is located. The driver currently assumes this is the same as
the platform device, which breaks when the iommu is outside of the
platform device (ie in the parent). Default to using the platform device,
but check to
https://bugs.freedesktop.org/show_bug.cgi?id=111087
--- Comment #9 from Ludovico de Nittis ---
(In reply to Michel Dänzer from comment #8)
> The Xorg log file indicates that Xorg starts up in 2560x1440, then an X
> client switches to 1920x1080 about 0.25s later (~23s after the kernel starts
> boo
On Wed, Jul 03, 2019 at 07:00:35AM -0700, 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.
>
> Signed-off-by: Rob Clark
> ---
> drivers/gpu/drm/msm/adreno/adreno_dev
On 2019-07-07 7:30 p.m., Stephen Rothwell wrote:
> Hi all,
>
> On Wed, 3 Jul 2019 17:09:16 -0400 Alex Deucher wrote:
>> On Wed, Jul 3, 2019 at 5:03 PM Kuehling, Felix
>> wrote:
>>> On 2019-07-03 10:10 a.m., Jason Gunthorpe wrote:
On Wed, Jul 03, 2019 at 01:55:08AM +, Kuehling, Felix wro
Hi Felix,
On Mon, 8 Jul 2019 15:26:22 + "Kuehling, Felix"
wrote:
>
> Thank you! Who will be that someone? It should probably be one of the
> maintainers of the trees Linux pulls from ...
That would be Dave (pushing drm) or Jason (pushing hmm), or both.
--
Cheers,
Stephen Rothwell
pgpsV
https://bugs.freedesktop.org/show_bug.cgi?id=111087
--- Comment #10 from Ludovico de Nittis ---
Created attachment 144727
--> https://bugs.freedesktop.org/attachment.cgi?id=144727&action=edit
dmesg with kernel option amdgpu.dc=0
--
You are receiving this mail because:
You are the assignee for
https://bugs.freedesktop.org/show_bug.cgi?id=111087
--- Comment #11 from Ludovico de Nittis ---
Created attachment 144728
--> https://bugs.freedesktop.org/attachment.cgi?id=144728&action=edit
Xorg log with kernel option amdgpu.dc=0
--
You are receiving this mail because:
You are the assignee
1 - 100 of 237 matches
Mail list logo
