Hi Emil,
On Fri, 1 Nov 2019 13:03:13 +
Emil Velikov wrote:
> From: Emil Velikov
>
> As mentioned by Christian, for drivers which support only primary nodes
> this changes the returned error from -EACCES into -EOPNOTSUPP/-ENOSYS.
Are you sure this is true for MODESET-only nodes (those tha
When enabling the CRTC after waking up from a power-saving mode, the
primary plane's framebuffer might be NULL, which leads to a stack trace
as shown below.
[ 632.624608] BUG: kernel NULL pointer dereference, address: 0048
[ 632.624631] #PF: supervisor read access in kernel mode
On Fri, Nov 22, 2019 at 09:32:45AM +0800, Philip Li wrote:
> On Thu, Nov 21, 2019 at 07:26:05AM +, Chris Wilson wrote:
> > Quoting kernel test robot (2019-11-21 07:19:43)
> > > Greetings,
> > >
> > > 0day kernel testing robot got the below dmesg and the first bad commit is
> > >
> > > https:/
https://bugzilla.kernel.org/show_bug.cgi?id=205675
Bug ID: 205675
Summary: Display locks up. AMDGPU timeout
Product: Drivers
Version: 2.5
Kernel Version: 5.4.0
Hardware: x86-64
OS: Linux
Tree: Mainline
On Tue, 2019-11-26 at 09:49 +0100, Daniel Vetter wrote:
> On Tue, Nov 26, 2019 at 02:29:26PM +0800, Bibby Hsieh wrote:
> > The DRM core takes care of all atomic state refcounting.
> > However, mediatek drm defers some work that accesses planes
> > and plane_states in drm_atomic_state, and must ther
Hi, Yongqiang:
On Tue, 2019-11-26 at 14:47 +0800, yongqiang@mediatek.com wrote:
> From: Yongqiang Niu
>
> This patch fix up 1440x900 dp display black screen issue
> the computed result will overflow rdma1 fifo max size
> when external display pixel clock bigger than 74MHZ
>
> Signed-off-by:
[AMD Official Use Only - Internal Distribution Only]
Reviewed-by: Emily Deng
>-Original Message-
>From: Grodzovsky, Andrey
>Sent: Tuesday, November 26, 2019 7:37 AM
>Cc: dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org; Koenig,
>Christian ; Deng, Emily
>; steven.pr...@arm.
Hey! Saw your comment on the RHBZ regarding this, figured I'd take a look
since I've got some DPCD backlight related fixes for one of your other laptops
on the list as well.
On Thu, 2019-10-10 at 00:13 +0800, Lee Shawn C wrote:
> This panel (manufacturer is SDC, product ID is 0x4141)
> used manufa
Hi all,
Today's linux-next merge of the tip tree got a conflict in:
drivers/gpu/drm/i915/Kconfig.debug
between commit:
d30213e533fa ("drm/i915: Fix Kconfig indentation")
from the drm tree and commit:
fb041bb7c0a9 ("locking/refcount: Consolidate implementations of refcount_t")
from the
I'm about to post some more review comments for the v2 version of this, but
some comments down below...
On Tue, 2019-10-08 at 12:19 +0300, Jani Nikula wrote:
> On Mon, 07 Oct 2019, Adam Jackson wrote:
> > On Mon, 2019-10-07 at 12:08 +0300, Jani Nikula wrote:
> >
> > > The problem with the EDID q
https://bugs.freedesktop.org/show_bug.cgi?id=110674
--- Comment #172 from line...@xcpp.org ---
I had dpm=2 as a module option. GPU initialization failure does not occur
without dpm=2
--
You are receiving this mail because:
You are the assignee for the bug.
[big snip]
> There is a sysfs attribute called "d3cold_allowed" which can be used
> for "blocking" D3cold, so can you please retest using that?
>
Hey-this is almost certainly not the right place in this thread to respond,
but this thread has gotten so deep evolution can't push the subject further
Hi Jyri.
Took a quick look - looks like a very nice driver.
Some drive by comments below.
I was left with the impression that there is a lot of code to support
vblank - and I wonder if there is some general code that can help you
here that you have missed.
Sam
On Tue, Nov 26, 2019 at 1
From: Thomas Hellstrom
The TTM module today uses a hack to be able to set a different page
protection than struct vm_area_struct::vm_page_prot. To be able to do
this properly, add and export vmf_insert_mixed_prot().
Cc: Andrew Morton
Cc: Michal Hocko
Cc: "Matthew Wilcox (Oracle)"
Cc: "Kirill
From: Thomas Hellstrom
We were using an ugly hack to set the page protection correctly.
Fix that and instead use vmf_insert_mixed_prot() and / or
vmf_insert_pfn_prot().
Also get the default page protection from
struct vm_area_struct::vm_page_prot rather than using vm_get_page_prot().
This way we
Hi Daniel,
Thanks for the comments, please see inline
W dniu 25.11.2019 o 09:55, Daniel Vetter pisze:
On Thu, Nov 21, 2019 at 06:22:44PM +0100, Andrzej Pietrasiewicz wrote:
These are useful for other users of afbc, e.g. rockchip.
Signed-off-by: Andrzej Pietrasiewicz
---
drivers/gpu/drm/Mak
I'm not well versed in MST bw validation, which might explain my confusion here
- so bear with me :)
...
On 2019-11-16 5:01 p.m., mikita.lip...@amd.com wrote:
> From: Mikita Lipski
>
> Adding PBN attribute to drm_dp_vcpi_allocation structure to
> keep track of how much bandwidth each Port requi
Hi Mihail.
On Tue, Nov 26, 2019 at 01:16:26PM +, Mihail Atanassov wrote:
> No functional change.
>
> Signed-off-by: Mihail Atanassov
> ---
> drivers/gpu/drm/sti/sti_dvo.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/sti/sti_dvo.c b/drivers/gpu
Hi Mihail.
> Ack, but with one caveat: bridge->dev is the struct drm_device that is
> the bridge client, we need to add a bridge->device (patch 29 in this
> series) which is the struct device that will manage the bridge lifetime.
Other places uses the variable name "drm" for a drm_device.
This is
Hi
Am 26.11.19 um 19:43 schrieb Gurchetan Singh:
> Commit b0e40e ("vram: Have VRAM MM call GEM VRAM functions directly")
> removed this.
>
> Signed-off-by: Gurchetan Singh
Reviewed-by: Thomas Zimmermann
Thanks! I'll add the patch into drm-misc-next.
Best regards
Thomas
> ---
> include/drm/
Commit b0e40e ("vram: Have VRAM MM call GEM VRAM functions directly")
removed this.
Signed-off-by: Gurchetan Singh
---
include/drm/drm_gem_vram_helper.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/drm/drm_gem_vram_helper.h
b/include/drm/drm_gem_vram_helper.h
index e040541a105f..0
On 2019-11-25 4:36 p.m., Zuo, Jerry wrote:
> Please kindly give a review on my latest revision. Thanks a lot.
>
Both patches are
Reviewed-by: Harry Wentland
Harry
> Regards,
> Jerry
>
> -Original Message-
> From: Jerry (Fangzhi) Zuo
> Sent: November 5, 2019 11:38 AM
> To: dri-devel@
On Tue, Nov 26, 2019 at 10:14:13AM +0100, Daniel Vetter wrote:
> 0 means 1 as the default, but it's mighty confusing if the block size
> for the first plane is spelled out explicitly, but not for the 2nd
> plane.
>
> No cc: stable because this is just confusion, but 0 functional issue.
Acked-by:
Looks like the shift and mask are reversed. Does this patch fix it?
Yes, the warning is gone and it still works. Thank you!
Tested-by: Meelis Roos
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listi
On Tue, Nov 26, 2019 at 4:55 PM Mihail Atanassov
wrote:
>
> Hi Daniel,
>
> Thanks for the quick review.
>
> On Tuesday, 26 November 2019 14:26:10 GMT Daniel Vetter wrote:
> > On Tue, Nov 26, 2019 at 01:15:59PM +, Mihail Atanassov wrote:
> > > A simple convenience function to initialize the str
Applied. thanks!
Alex
On Tue, Nov 26, 2019 at 3:15 AM Jules Irenge wrote:
>
> Replace 0 with NULL to fix sparse tool warning
> warning: Using plain integer as NULL pointer
>
> Signed-off-by: Jules Irenge
> ---
> drivers/gpu/drm/radeon/radeon_audio.c | 2 +-
> 1 file changed, 1 insertion(+),
On Tue, Nov 26, 2019 at 7:10 AM Dan Carpenter wrote:
>
> Originally the last WREG32_SOC15() was a part of the if statement block
> but the curly braces are on the wrong line.
>
> Fixes: bb0db70f3f75 ("drm/amdgpu: separate JPEG1.0 code out from VCN1.0")
> Signed-off-by: Dan Carpenter
Applied. Th
Hi Daniel,
Thanks for the quick review.
On Tuesday, 26 November 2019 14:26:10 GMT Daniel Vetter wrote:
> On Tue, Nov 26, 2019 at 01:15:59PM +, Mihail Atanassov wrote:
> > A simple convenience function to initialize the struct drm_bridge.
> >
> > Signed-off-by: Mihail Atanassov
>
> The comm
On Tuesday, 26 November 2019 15:27:16 GMT Russell King - ARM Linux admin wrote:
> What happened with the patches I posted doing exactly this?
Hi Russell,
>
> [snip]
> >
> > Russell King (1):
> > drm/bridge: add support for device links to bridge
^^^
Do you mean this one? It's 29/30 in the se
On Tuesday, 26 November 2019 14:35:34 GMT Daniel Vetter wrote:
> On Tue, Nov 26, 2019 at 01:16:26PM +, Mihail Atanassov wrote:
> > From: Russell King
> >
> > Bridge devices have been a potential for kernel oops as their lifetime
> > is independent of the DRM device that they are bound to. He
On 11/26/19 4:08 AM, Christian König wrote:
Am 25.11.19 um 17:51 schrieb Steven Price:
On 25/11/2019 14:10, Andrey Grodzovsky wrote:
When the sched thread is parked we assume ring_mirror_list is
not accessed from here.
FWIW I don't think this is necessary. kthread_park() will wait until the
t
Ping
Andrey
On 11/25/19 3:51 PM, Andrey Grodzovsky wrote:
Problem:
Due to a race between drm_sched_cleanup_jobs in sched thread and
drm_sched_job_timedout in timeout work there is a possiblity that
bad job was already freed while still being accessed from the
timeout thread.
Fix:
Instead of ju
I recently updated amd-staging-drm-next. Apply whatever makes sense for now
and it'll naturally fall out in the next rebase.
Alex
From: Grodzovsky, Andrey
Sent: Monday, November 25, 2019 7:09 PM
To: Deng, Emily
Cc: dri-devel@lists.freedesktop.org ;
amd-...@lis
> -Original Message-
> From: amd-gfx On Behalf Of
> Christian König
> Sent: 2019/November/26, Tuesday 5:10 AM
> To: Jules Irenge ; Deucher, Alexander
>
> Cc: Zhou, David(ChunMing) ; airl...@linux.ie;
> linux-ker...@vger.kernel.org; amd-...@lists.freedesktop.org; dri-
> de...@lists.freed
What happened with the patches I posted doing exactly this?
On Tue, Nov 26, 2019 at 01:15:58PM +, Mihail Atanassov wrote:
> Hi all,
>
> This series adds device links support to drm_bridge. The motivation
> behind it is that a drm_bridge in a module could get removed under the
> feet of the br
On Fri, Nov 22, 2019 at 07:56:23PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Add selftests for drm_rect. A few basic ones for clipped and unclipped
> cases, and a few special ones for specific bugs we had in the code.
>
> I'm too lazy to think of more corner cases to check at this ti
On Tue, Nov 26, 2019 at 07:03:58AM -0800, Devarsh Thakkar wrote:
> Add inline function to derive floating value of vertical
> refresh rate from pixel clock, horizontal total size and
> vertical total size.
>
> Use this function to find suitable mode having vrefresh
> value which is matching with u
On Tue, Nov 26, 2019 at 03:52:13PM +0100, Daniel Vetter wrote:
> This was forgotten in f96bdf564f3e ("drm/rect: Handle rounding errors
> in drm_rect_clip_scaled, v3.")
>
> Spotted while reviewing patches from Ville touching this area.
>
> Fixes: f96bdf564f3e ("drm/rect: Handle rounding errors in
On Fri, Nov 22, 2019 at 07:56:22PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Now that we've constrained the clipped source rectangle such
> that it can't have negative dimensions doing the same for the
> dst rectangle seems appropriate. Should at least result in
> the clipped src and
> -Original Message-
> From: amd-gfx On Behalf Of
> Christian König
> Sent: 2019/November/26, Tuesday 5:10 AM
> To: Jules Irenge ; Deucher, Alexander
>
> Cc: Zhou, David(ChunMing) ; airl...@linux.ie;
> linux-ker...@vger.kernel.org; amd-...@lists.freedesktop.org; dri-
> de...@lists.freed
This was forgotten in f96bdf564f3e ("drm/rect: Handle rounding errors
in drm_rect_clip_scaled, v3.")
Spotted while reviewing patches from Ville touching this area.
Fixes: f96bdf564f3e ("drm/rect: Handle rounding errors in drm_rect_clip_scaled,
v3.")
Cc: Maarten Lankhorst
Cc: Benjamin Gaignard
On Fri, Nov 22, 2019 at 07:56:21PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Limit the scaled clip to only clip at most dst_w/h pixels.
> This avoids the problem with clip_scaled() not being able
> to return negative values. Since new_src_w/h is now properly
> bounded we can remove th
On Tue, Nov 26, 2019 at 3:39 AM Meelis Roos wrote:
>
> I tried latest (5.4) custom kernel (with UBSAN) on my Dell D600 laptop and
> found that it exhibits a
> UBSAN warning triggered by userspace ioctl. Here is dmesg with anything
> radeon-related + the warning, and config:
>
> [ 17.659534] [d
Op 26-11-2019 om 15:36 schreef Daniel Vetter:
> On Tue, Nov 26, 2019 at 03:25:16PM +0100, Maarten Lankhorst wrote:
>> Commit 7f0de8d80816 ("dma-buf: Drop dma_buf_k(un)map") removed map/unmap
>> handlers, but they still existed in udmabuf. Remove them there as well
>>
>> Signed-off-by: Maarten Lankh
Shift and mask were reversed. Noticed by chance.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/r100.c | 4 ++--
drivers/gpu/drm/radeon/r200.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index 708
On Fri, Nov 22, 2019 at 07:56:20PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Check for zero width/height destination rectangle in
> drm_rect_clip_scaled() to avoid a division by zero.
>
> Cc: sta...@vger.kernel.org
> Fixes: f96bdf564f3e ("drm/rect: Handle rounding errors in
> drm_re
On Tue, Nov 26, 2019 at 03:25:16PM +0100, Maarten Lankhorst wrote:
> Commit 7f0de8d80816 ("dma-buf: Drop dma_buf_k(un)map") removed map/unmap
> handlers, but they still existed in udmabuf. Remove them there as well
>
> Signed-off-by: Maarten Lankhorst
> Fixes: 7f0de8d80816 ("dma-buf: Drop dma_buf
On Tue, Nov 26, 2019 at 01:16:26PM +, Mihail Atanassov wrote:
> From: Russell King
>
> Bridge devices have been a potential for kernel oops as their lifetime
> is independent of the DRM device that they are bound to. Hence, if a
> bridge device is unbound while the parent DRM device is using
On Tue, Nov 26, 2019 at 01:15:59PM +, Mihail Atanassov wrote:
> A simple convenience function to initialize the struct drm_bridge.
>
> Signed-off-by: Mihail Atanassov
The commit message here leaves figuring out why we need this to the
reader. Reading ahead the reasons seems to be to roll out
Commit 7f0de8d80816 ("dma-buf: Drop dma_buf_k(un)map") removed map/unmap
handlers, but they still existed in udmabuf. Remove them there as well
Signed-off-by: Maarten Lankhorst
Fixes: 7f0de8d80816 ("dma-buf: Drop dma_buf_k(un)map")
Cc: Sumit Semwal
Cc: Daniel Vetter
Cc: linux-me...@vger.kernel.
https://bugzilla.kernel.org/show_bug.cgi?id=205661
Bug ID: 205661
Summary: Upgrade to 5.4 from K5.3.13 fails x2 attempts
Product: Drivers
Version: 2.5
Kernel Version: Kernel 5.4
Hardware: All
OS: Linux
Tree: M
https://bugs.freedesktop.org/show_bug.cgi?id=110674
Alex Deucher changed:
What|Removed |Added
Attachment #146026|text/x-log |text/plain
mime type|
Quoting Niranjana Vishwanathapura (2019-11-22 22:57:21)
> Shared Virtual Memory (SVM) allows the programmer to use a single virtual
> address space which will be shared between threads executing on CPUs and GPUs.
> It abstracts away from the user the location of the backing memory, and hence
> simp
Quoting Niranjan Vishwanathapura (2019-11-25 18:40:57)
> On Mon, Nov 25, 2019 at 09:59:37AM +, Chris Wilson wrote:
> >Quoting Niranjana Vishwanathapura (2019-11-22 20:57:24)
> >> Shared Virtual Memory (SVM) runtime allocator support allows
> >> binding a shared virtual address to a buffer objec
To mimic simple-pipe, we initialize the connector before the rest of
the display pipeline.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/udl/udl_connector.c | 7 +++
drivers/gpu/drm/udl/udl_drv.h | 2 +-
drivers/gpu/drm/udl/udl_modeset.c | 16 ++--
3 files change
The udl driver stores the currently active framebuffer to know from
where to accept damage updates.
With the conversion to plane-state damage handling, this is not necessary
any longer. The currently active framebuffer and damaged area are always
stored in the plane state.
Signed-off-by: Thomas Z
The infrastruture for atomic modesetting allows us to use the generic
code for dirty-FB and damage handling. Switch over udl and remove the
driver's implementation.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/udl/udl_drv.h | 5 ---
drivers/gpu/drm/udl/udl_fb.c | 67 ---
The only caller of udl_handle_damage() in the plane-update function
in udl_modeset.c. Move udl_handle_damage() there, make it static, and
remove several left-over macros.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/udl/Makefile | 2 +-
drivers/gpu/drm/udl/udl_drv.h | 3 -
d
The removed functionality is provided by simple-pipe helpers.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/udl/Makefile | 2 +-
drivers/gpu/drm/udl/udl_drv.h | 3 -
drivers/gpu/drm/udl/udl_encoder.c | 70 ---
drivers/gpu/drm/udl/udl_modeset.c | 138 -
With only a single display pipeline and primary plane, udl is perfect
for simple-pipe helpers. Patches 1 to 3 do the convertion. This enables
atomic modesetting for udl devices.
Patches 4 to 7 clean up handling of color depth and framebuffers. With
universal planes that come with simple pipe, disp
The current default color depth of 24 bpp is not even supported by
the driver. Being the native format for communicating with the adapter,
16 bpp is the correct choice.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/udl/udl_drv.c | 2 +-
drivers/gpu/drm/udl/udl_modeset.c | 2 +-
2 file
Udl has a single display pipeline with aprimary plane; perfect for
simple-pipe helpers. Convert it over. The old encoder and CRTC code
becomes unused and obsolete.
Exported formats for the primary plane are RGB565 and XRGB, with
the latter being emulated. The 16-bit format is the default and w
Quoting Niranjana Vishwanathapura (2019-11-22 22:57:23)
> Define UAPI for Shared Virtual Memory (SVM) fucntionality including
> SVM capability and configurability.
> When there is no GPU page fault support available, add ioctls
> to explicitly bind and migrate virtual address ranges.
>
> Cc: Joona
To support more transmitters, we need to allow non-component framework
bridges to be attached to a dummy drm_encoder in our driver.
A/B tested for equivalence against tda998x, and also tested ti_tfp410 as
an alternate transmitter.
Signed-off-by: Mihail Atanassov
---
.../gpu/drm/arm/display/kome
Hi all,
This series adds device links support to drm_bridge. The motivation
behind it is that a drm_bridge in a module could get removed under the
feet of the bridge user without warning, so we need a way to remove and
reprobe the client as needed to avoid peering into the void.
1: Add a drm_brid
No functional change.
Signed-off-by: Mihail Atanassov
---
drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c
b/drivers/gpu/drm/bridge/megachips-stdp-ge-b850
No functional change: it's not used anywhere.
Signed-off-by: Mihail Atanassov
---
drivers/gpu/drm/rcar-du/rcar_lvds.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_lvds.c
b/drivers/gpu/drm/rcar-du/rcar_lvds.c
index ac1f29bacfcb..168a718cbcbd 10
No functional change.
Signed-off-by: Mihail Atanassov
---
drivers/gpu/drm/sti/sti_dvo.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/sti/sti_dvo.c b/drivers/gpu/drm/sti/sti_dvo.c
index 68289b0b063a..20a3956b33bc 100644
--- a/drivers/gpu/drm/sti/sti_dvo.c
No functional change.
Signed-off-by: Mihail Atanassov
---
drivers/gpu/drm/bridge/tc358764.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/bridge/tc358764.c
b/drivers/gpu/drm/bridge/tc358764.c
index db298f550a5a..861d4df687ee 100644
--- a/drivers/gpu/drm/
No functional change.
Signed-off-by: Mihail Atanassov
---
drivers/gpu/drm/mcde/mcde_dsi.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/mcde/mcde_dsi.c b/drivers/gpu/drm/mcde/mcde_dsi.c
index 42fff811653e..d9b9253acccf 100644
--- a/drivers/gpu/drm/mcde/mcd
No functional change.
Signed-off-by: Mihail Atanassov
---
drivers/gpu/drm/i2c/tda998x_drv.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c
b/drivers/gpu/drm/i2c/tda998x_drv.c
index a63790d32d75..f7dfa694aff7 100644
--- a/drivers/gpu/dr
No functional change.
Signed-off-by: Mihail Atanassov
---
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
index 43abf01ebd4c..4e236b46f913 100644
--- a/dr
No functional change.
Signed-off-by: Mihail Atanassov
---
drivers/gpu/drm/bridge/ti-tfp410.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/bridge/ti-tfp410.c
b/drivers/gpu/drm/bridge/ti-tfp410.c
index aa3198dc9903..377eca989ff3 100644
--- a/drivers/gpu
No functional change.
Signed-off-by: Mihail Atanassov
---
drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
index b6e793bb653c..05
No functional change.
Signed-off-by: Mihail Atanassov
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index dbe38a54870b..6c71ffc9df5a 1
No functional change.
Signed-off-by: Mihail Atanassov
---
drivers/gpu/drm/bridge/cdns-dsi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/bridge/cdns-dsi.c
b/drivers/gpu/drm/bridge/cdns-dsi.c
index 3a5bd4e7fd1e..58b2aa8b6c24 100644
--- a/drivers/gpu/drm
No functional change.
Signed-off-by: Mihail Atanassov
---
drivers/gpu/drm/bridge/nxp-ptn3460.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/bridge/nxp-ptn3460.c
b/drivers/gpu/drm/bridge/nxp-ptn3460.c
index 57ff01339559..2656a188b434 100644
--- a/driver
No functional change.
Signed-off-by: Mihail Atanassov
---
drivers/gpu/drm/bridge/tc358767.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/bridge/tc358767.c
b/drivers/gpu/drm/bridge/tc358767.c
index 8029478ffebb..7846c1925cbb 100644
--- a/drivers/gpu/drm/b
No functional change.
Signed-off-by: Mihail Atanassov
---
drivers/gpu/drm/rcar-du/rcar_lvds.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_lvds.c
b/drivers/gpu/drm/rcar-du/rcar_lvds.c
index 8c6c172bbf2e..ac1f29bacfcb 100644
--- a/drivers/
No functional change.
Signed-off-by: Mihail Atanassov
---
drivers/gpu/drm/bridge/dumb-vga-dac.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/bridge/dumb-vga-dac.c
b/drivers/gpu/drm/bridge/dumb-vga-dac.c
index cc33dc411b9e..896f27272e38 100644
--- a/d
No functional change.
Signed-off-by: Mihail Atanassov
---
drivers/gpu/drm/mediatek/mtk_hdmi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c
b/drivers/gpu/drm/mediatek/mtk_hdmi.c
index f684947c5243..9761a80674d9 100644
--- a/drivers/g
No functional change.
Signed-off-by: Mihail Atanassov
---
drivers/gpu/drm/bridge/analogix/analogix-anx6345.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
index b4f
From: Russell King
Bridge devices have been a potential for kernel oops as their lifetime
is independent of the DRM device that they are bound to. Hence, if a
bridge device is unbound while the parent DRM device is using them, the
parent happily continues to use the bridge device, calling the dr
No functional change.
Signed-off-by: Mihail Atanassov
---
drivers/gpu/drm/bridge/thc63lvd1024.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/bridge/thc63lvd1024.c
b/drivers/gpu/drm/bridge/thc63lvd1024.c
index 3d74129b2995..abe806db5f4d 100644
--- a/
No functional change: no logic depends on driver_private being NULL, so
it's safe to set it earlier in exynos_mic_probe.
Signed-off-by: Mihail Atanassov
---
drivers/gpu/drm/exynos/exynos_drm_mic.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/exynos/e
No functional change.
Signed-off-by: Mihail Atanassov
---
drivers/gpu/drm/bridge/sii9234.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/bridge/sii9234.c b/drivers/gpu/drm/bridge/sii9234.c
index f81f81b7051f..bfd3832baa1a 100644
--- a/drivers/gpu/drm/bridg
No functional change.
Signed-off-by: Mihail Atanassov
---
drivers/gpu/drm/bridge/sii902x.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/bridge/sii902x.c b/drivers/gpu/drm/bridge/sii902x.c
index b70e8c5cf2e1..2a9db621484d 100644
--- a/drivers/gpu/drm/br
A simple convenience function to initialize the struct drm_bridge.
Signed-off-by: Mihail Atanassov
---
drivers/gpu/drm/drm_bridge.c | 29 +
include/drm/drm_bridge.h | 4
2 files changed, 33 insertions(+)
diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/g
No functional change.
Signed-off-by: Mihail Atanassov
---
drivers/gpu/drm/bridge/parade-ps8622.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/bridge/parade-ps8622.c
b/drivers/gpu/drm/bridge/parade-ps8622.c
index b7a72dfdcac3..8454dbb238bb 100644
--- a/dr
No functional change.
Signed-off-by: Mihail Atanassov
---
drivers/gpu/drm/bridge/panel.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/bridge/panel.c b/drivers/gpu/drm/bridge/panel.c
index f4e293e7cf64..91d68d0337cc 100644
--- a/drivers/gpu/drm/bridge
No functional change.
Signed-off-by: Mihail Atanassov
---
drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
index 9e13e466e72c..73600d8
No functional change.
Signed-off-by: Mihail Atanassov
---
drivers/gpu/drm/bridge/sil-sii8620.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c
b/drivers/gpu/drm/bridge/sil-sii8620.c
index 4c0eef406eb1..482dc2291350 100644
--- a/drivers/
No functional change.
Signed-off-by: Mihail Atanassov
---
drivers/gpu/drm/bridge/lvds-encoder.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/bridge/lvds-encoder.c
b/drivers/gpu/drm/bridge/lvds-encoder.c
index e2132a8d5106..155406510416 100644
--- a/
No functional change.
Signed-off-by: Mihail Atanassov
---
drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
b/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
index
Quoting Dan Carpenter (2019-11-26 12:50:03)
> We should be unmapping "page" instead of "s". This code originally used
> kmap_atomic() before it was changed to kmap(). The two mapping
> functions are different which leads to this common mistake.
>
> Fixes: 3e749f5199e1 ("drm/i915: Avoid atomic co
We should be unmapping "page" instead of "s". This code originally used
kmap_atomic() before it was changed to kmap(). The two mapping
functions are different which leads to this common mistake.
Fixes: 3e749f5199e1 ("drm/i915: Avoid atomic context for error capture")
Signed-off-by: Dan Carpenter
Originally the last WREG32_SOC15() was a part of the if statement block
but the curly braces are on the wrong line.
Fixes: bb0db70f3f75 ("drm/amdgpu: separate JPEG1.0 code out from VCN1.0")
Signed-off-by: Dan Carpenter
---
From static analysis (Smatch). Not tested.
drivers/gpu/drm/amd/amdgpu/j
On Tue, Nov 26, 2019 at 10:54:47AM +, james qian wang (Arm Technology
China) wrote:
> From: "James Qian Wang (Arm Technology China)"
>
> Split sysfs config_id bitfiles to multiple separated sysfs files.
>
> Signed-off-by: James Qian Wang (Arm Technology China)
>
I guess Dave&my questions
Reviewed-by: Christian König
Am 25.11.19 um 06:30 schrieb Quan, Evan:
Reviewed-by: Evan Quan
-Original Message-
From: amd-gfx On Behalf Of Alex
Deucher
Sent: Saturday, November 23, 2019 3:19 AM
To: amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
Cc: Deucher, Alexander
https://bugs.freedesktop.org/show_bug.cgi?id=110674
--- Comment #171 from line...@xcpp.org ---
Created attachment 146026
--> https://bugs.freedesktop.org/attachment.cgi?id=146026&action=edit
5.4.0-arch1-1 GPU initialization fails
With kernel version 5.4.0-arch1-1 the GPU can flat out no longer
1 - 100 of 153 matches
Mail list logo
