Fix the following coccicheck warnings:
./drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c:956:52-57: WARNING:
conversion to bool not needed here.
./drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c:8311:16-21: WARNING:
conversion to bool not needed here.
Reported-by: Abaci Robot
Signed-off-by:
Hi,
shall I merge this patch?
Am 02.03.21 um 18:57 schrieb Jagan Teki:
STM ltdc driver uses an empty implementation for its encoder.
Replace the code with the generic simple encoder.
Signed-off-by: Jagan Teki
---
drivers/gpu/drm/stm/ltdc.c | 12 ++--
1 file changed, 2 insertions(+)
On Thu, Mar 4, 2021 at 2:57 AM Nicolas Boichat wrote:
> On Thu, Mar 4, 2021 at 8:41 AM Linus Walleij wrote:
> >
> > A recent patch renaming MIPI_DSI_MODE_EOT_PACKET to
> > MIPI_DSI_MODE_NO_EOT_PACKET brought to light the
> > misunderstanding in the current MCDE driver and all
> > its associated p
On Tue, Mar 02, 2021 at 03:44:44PM +0300, Dmitry Osipenko wrote:
> Display controller (DC) performs isochronous memory transfers, and thus,
> has a requirement for a minimum memory bandwidth that shall be fulfilled,
> otherwise framebuffer data can't be fetched fast enough and this results
> in a D
On Wed, 3 Mar 2021 12:44:33 -0800
"Navare, Manasi" wrote:
> On Wed, Mar 03, 2021 at 10:47:44AM +0200, Pekka Paalanen wrote:
> > On Tue, 2 Mar 2021 12:41:32 -0800
> > Manasi Navare wrote:
> >
> > > In case of a modeset where a mode gets split across mutiple CRTCs
> > > in the driver specific
Hi Laurent,
On Thu, Mar 4, 2021 at 4:29 AM Laurent Pinchart
wrote:
>
> Hi Jagan,
>
> On Wed, Mar 03, 2021 at 08:08:35PM +0530, Jagan Teki wrote:
> > On Wed, Feb 24, 2021 at 6:44 PM Laurent Pinchart wrote:
> > > On Wed, Feb 24, 2021 at 06:07:43PM +0530, Jagan Teki wrote:
> > > > On Mon, Feb 15, 20
ICN6211 is MIPI-DSI to RGB Converter bridge from Chipone.
It has a flexible configuration of MIPI DSI signal input and
produce RGB565, RGB666, RGB888 output format.
Add bridge driver for it.
Signed-off-by: Jagan Teki
---
Changes for v4:
- added regulators
- replace reset with EN
- fixed warning
ICN6211 is MIPI-DSI to RGB Converter bridge from Chipone.
It has a flexible configuration of MIPI DSI signal input and
produces RGB565, RGB666, RGB888 output format.
Add dt-bingings for it.
Signed-off-by: Jagan Teki
---
Changes for v4:
- fixed Laurent comments
- added regulators
- replace reset
Fix a warning, pointing to an early deference of a variable before
check. This bug was introduced in the following commit.
commit 4259ff7ae509
("drm/msm/dpu: add support for pcc color block in dpu driver")
Reported-by: kernel test robot
Reported-by: Dan Carpenter
Signed-off-by: Kalyan Thota
--
From: Colin Ian King
The surface_id struct field in head is not being initialized and
static analysis warns that this is being passed through to
dev->monitors_config->heads[i] on an assignment. Clear up this
warning by initializing it to zero.
Addresses-Coverity: ("Uninitialized scalar variable"
Hi Thomas,
I wait a few days before merging it.
Thank you for your help.
Best regards
Yannick
On 3/4/21 9:21 AM, Thomas Zimmermann wrote:
Hi,
shall I merge this patch?
Am 02.03.21 um 18:57 schrieb Jagan Teki:
STM ltdc driver uses an empty implementation for its encoder.
Replace the code wi
Hello Sir/Madam,
I am trying to render some stuff using DRM with Qt GUI application and
decoded stream from Intel H/w decoder.
I have two applications one is for GUI content and another one is for
decoded video streams. While doing this I am facing an issue that only
singal process acquires DRM m
https://bugzilla.kernel.org/show_bug.cgi?id=211997
Stefan de Konink (ste...@konink.de) changed:
What|Removed |Added
Status|NEW |RESOLVED
Re
https://bugzilla.kernel.org/show_bug.cgi?id=211997
--- Comment #4 from Paul Menzel (pmenzel+bugzilla.kernel@molgen.mpg.de) ---
Thank you for updating the status. Can you please mark it as a duplicate of bug
#211649 [1].
[1]: https://bugzilla.kernel.org/show_bug.cgi?id=211649
--
You may repl
https://bugzilla.kernel.org/show_bug.cgi?id=211649
Paul Menzel (pmenzel+bugzilla.kernel@molgen.mpg.de) changed:
What|Removed |Added
CC||
On Thu, Mar 04, 2021 at 08:42:55AM +0100, Thomas Zimmermann wrote:
> (cc'ing Gerd)
>
> This might be related to the recent clean-up patches for the BO handling in
> qxl.
Yes, it is. Fixed in drm-misc-next, cherry-picked into drm-misc-fixes,
hopefully lands in -rc2.
take care,
Gerd
__
Hi Daniel,
On 3/4/21 12:50 PM, Daniel Lezcano wrote:
Currently the default behavior is to manually having the devfreq
backend to register themselves as a devfreq cooling device.
There are no so many and actually it makes more sense to register the
devfreq device when adding it.
Consequently, e
https://bugzilla.kernel.org/show_bug.cgi?id=211649
--- Comment #17 from Alex Deucher (alexdeuc...@gmail.com) ---
(In reply to Paul Menzel from comment #16)
> Can this bug be closed then?
Only the person that opens the bug can close it, but yes, it can be closed.
--
You may reply to this email t
On Wed, Mar 03, 2021 at 04:57:57PM +0100, Christian König wrote:
> QXL indeed unrefs pinned BOs and the warnings are spamming peoples log files.
>
> Make sure we warn only once until the QXL driver is fixed.
> - dma_resv_assert_held(bo->base.resv);
> + if (!bo->deleted)
> + dm
https://bugzilla.kernel.org/show_bug.cgi?id=211649
youling...@gmail.com changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Hi Daniel,
As Lukasz's comment, actually some devfreq devices like memory bus
might not affect the thermal critically. In the mainline,
there are four types devfreq as following:
1. GPU
2. UFS Storage
3. DMC (Memory Controller)
4. Memory bus like AMBA AXI
I think that you can specify this devfre
I was doing some testing in a KVM with a kernel based on this commit:
f69d02e37a85 (origin/master, dhowells/master, master) Merge tag
'misc-5.12-2021-03-02' of git://git.kernel.dk/linux-block
...with some ceph+fscache patches on top, and am getting a ton of warnings
popping that look like th
On 2021-03-01 08:42, Christoph Hellwig wrote:
Use explicit methods for setting and querying the information instead.
Now that everyone's using iommu-dma, is there any point in bouncing this
through the drivers at all? Seems like it would make more sense for the
x86 drivers to reflect their pr
On 2021-03-01 08:42, Christoph Hellwig wrote:
Signed-off-by: Christoph Hellwig
Moreso than the previous patch, where the feature is at least relatively
generic (note that there's a bunch of in-flight development around
DOMAIN_ATTR_NESTING), I'm really not convinced that it's beneficial to
b
On Fri, Feb 26, 2021 at 01:53:00PM +0100, Marjan Pascolo wrote:
> Hi Maxime,
>
> Il 17/02/2021 12:03, Maxime Ripard ha scritto:
> > Hi,
> >
> > On Wed, Feb 10, 2021 at 05:22:37PM +0100, Marjan Pascolo wrote:
> > > On Allwinner SoC interrupt debounce can be controlled by two oscillator
> > > (32KH
If tbo.mem.bus.caching is cached, buffer is intended to be mapped
as cached from CPU. Map it with ioremap_cache.
This wasn't necessary before as device memory was never mapped
as cached from CPU side. It becomes necessary for aldebaran as
device memory is mapped cached from CPU.
Signed-off-by: Oa
On Mon, Mar 01, 2021 at 07:20:59PM +0200, Ville Syrjälä wrote:
> On Mon, Mar 01, 2021 at 11:59:46AM -0500, Steven Rostedt wrote:
> >
> > On my test box with latest v5.12-rc1, running with all trace events
> > enabled, I consistently trigger this warning.
> >
> > It appears to get triggered by the
I was wondering if a managed version of such API exists but looks like
none. We only have devm_ioremap_wc but that is valid only for
PAGE_CACHE_MODE_WC whereas ioremap_cache uses _WB. One more small
comment below.
Acked-by: Rajneesh Bhardwaj
On 3/4/2021 11:04 AM, Oak Zeng wrote:
If tbo.mem
On 3/4/21 4:53 PM, Daniel Lezcano wrote:
Hi Lukasz,
thanks for commenting this patch,
On 04/03/2021 14:47, Lukasz Luba wrote:
Hi Daniel,
On 3/4/21 12:50 PM, Daniel Lezcano wrote:
Currently the default behavior is to manually having the devfreq
backend to register themselves as a devfreq
Am 04.03.21 um 18:01 schrieb Bhardwaj, Rajneesh:
I was wondering if a managed version of such API exists but looks like
none. We only have devm_ioremap_wc but that is valid only for
PAGE_CACHE_MODE_WC whereas ioremap_cache uses _WB. One more small
comment below.
Acked-by: Rajneesh Bhardwaj
https://bugzilla.kernel.org/show_bug.cgi?id=211649
Stefan de Konink (ste...@konink.de) changed:
What|Removed |Added
CC||ste...@konink.de
--
https://bugzilla.kernel.org/show_bug.cgi?id=211997
Stefan de Konink (ste...@konink.de) changed:
What|Removed |Added
Resolution|PATCH_ALREADY_AVAILABLE |DUPLICATE
--- Comme
On 3/4/2021 12:31 PM, Christian König wrote:
[CAUTION: External Email]
Am 04.03.21 um 18:01 schrieb Bhardwaj, Rajneesh:
I was wondering if a managed version of such API exists but looks like
none. We only have devm_ioremap_wc but that is valid only for
PAGE_CACHE_MODE_WC whereas ioremap_cache
Am 03.03.21 um 14:20 schrieb Thomas Gleixner:
From: Thomas Gleixner
There is no reason to disable pagefaults and preemption as a side effect of
kmap_atomic_prot().
Use kmap_local_page_prot() instead and document the reasoning for the
mapping usage with the given pgprot.
Remove the NULL poin
Am 2021-03-01 um 3:46 a.m. schrieb Thomas Hellström (Intel):
>
> On 3/1/21 9:32 AM, Daniel Vetter wrote:
>> On Wed, Jan 06, 2021 at 10:01:09PM -0500, Felix Kuehling wrote:
>>> From: Philip Yang
>>>
>>> Register vram memory as MEMORY_DEVICE_PRIVATE type resource, to
>>> allocate vram backing pages
Am 04.03.21 um 15:05 schrieb Gerd Hoffmann:
On Wed, Mar 03, 2021 at 04:57:57PM +0100, Christian König wrote:
QXL indeed unrefs pinned BOs and the warnings are spamming peoples log files.
Make sure we warn only once until the QXL driver is fixed.
- dma_resv_assert_held(bo->base.resv);
+
Am 04.03.21 um 18:40 schrieb Bhardwaj, Rajneesh:
On 3/4/2021 12:31 PM, Christian König wrote:
[CAUTION: External Email]
Am 04.03.21 um 18:01 schrieb Bhardwaj, Rajneesh:
I was wondering if a managed version of such API exists but looks like
none. We only have devm_ioremap_wc but that is vali
> On Mar 3, 2021, at 08:20, Thomas Gleixner wrote:
>
> From: Thomas Gleixner
>
> There is no reason to disable pagefaults and preemption as a side effect of
> kmap_atomic_prot().
>
> Use kmap_local_page_prot() instead and document the reasoning for the
> mapping usage with the given pgprot.
Hi Oak,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on drm-tip/drm-tip linus/master v5.12-rc1 next-20210304]
[cannot apply to tegra-drm/drm/tegra/for-next drm-exynos/exynos-drm-next
drm/drm-next]
[If your patch is
Hi Oak,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on drm-tip/drm-tip linus/master v5.12-rc1 next-20210304]
[cannot apply to tegra-drm/drm/tegra/for-next drm-exynos/exynos-drm-next
drm/drm-next]
[If your patch is
From: Mark Yacoub
To initialize the framebuffer, use drm_gem_fb_init_with_funcs which
verifies that the BO size can fit the FB size by calculating the minimum
expected size of each plane.
The bug was caught using igt-gpu-tools test: kms_addfb_basic.too-high
and kms_addfb_basic.bo-too-small
Test
If tbo.mem.bus.caching is cached, buffer is intended to be mapped
as cached from CPU. Map it with ioremap_cache.
This wasn't necessary before as device memory was never mapped
as cached from CPU side. It becomes necessary for aldebaran as
device memory is mapped cached from CPU.
Signed-off-by: Oa
04.03.2021 02:08, Michał Mirosław пишет:
> On Tue, Mar 02, 2021 at 03:44:44PM +0300, Dmitry Osipenko wrote:
>> Display controller (DC) performs isochronous memory transfers, and thus,
>> has a requirement for a minimum memory bandwidth that shall be fulfilled,
>> otherwise framebuffer data can't be
Document all of the DRM_CAP_* defines.
Signed-off-by: Simon Ser
Cc: Daniel Vetter
Cc: Pekka Paalanen
---
include/uapi/drm/drm.h | 100 +++--
1 file changed, 96 insertions(+), 4 deletions(-)
diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index
On Thu, Mar 4, 2021 at 7:48 AM Robin Murphy wrote:
>
> On 2021-03-01 08:42, Christoph Hellwig wrote:
> > Signed-off-by: Christoph Hellwig
>
> Moreso than the previous patch, where the feature is at least relatively
> generic (note that there's a bunch of in-flight development around
> DOMAIN_ATTR
Apologies for letting so much time pass since the last revision!
The point of this series is trying to add both deferred-freeing
logic as well as a page pool to the DMA-BUF system heap to improve
allocation performance.
This is desired, as the combination of deferred freeing along
with the page p
This adds a shrinker controlled page pool, extracted
out of the ttm_pool logic, and abstracted out a bit
so it can be used by other non-ttm drivers.
Cc: Daniel Vetter
Cc: Christian Koenig
Cc: Sumit Semwal
Cc: Liam Mark
Cc: Chris Goldsworthy
Cc: Laura Abbott
Cc: Brian Starkey
Cc: Hridya Vals
This patch reworks the ttm_pool logic to utilize the recently
added drm_page_pool code.
This adds drm_page_pool structures to the ttm_pool_type
structures, and then removes all the ttm_pool_type shrinker
logic (as its handled in the drm_page_pool shrinker).
NOTE: There is one mismatch in the inte
This patch provides infrastructure for deferring buffer frees.
This is a feature ION provided which when used with some form
of a page pool, provides a nice performance boost in an
allocation microbenchmark. The reason it helps is it allows the
page-zeroing to be done out of the normal allocation/
Utilize the drm pagepool code to speed up allocation
performance.
This is similar to the ION pagepool usage, but tries to
utilize generic code instead of a custom implementation.
Cc: Daniel Vetter
Cc: Christian Koenig
Cc: Sumit Semwal
Cc: Liam Mark
Cc: Chris Goldsworthy
Cc: Laura Abbott
Cc:
Utilize the deferred free helper library in the system heap.
This provides a nice performance bump and puts the
system heap performance on par with ION.
Cc: Daniel Vetter
Cc: Christian Koenig
Cc: Sumit Semwal
Cc: Liam Mark
Cc: Chris Goldsworthy
Cc: Laura Abbott
Cc: Brian Starkey
Cc: Hridya
The clock framework makes it simple to deal with an optional clock.
You can call clk_get_optional() and if the clock isn't specified it'll
just return NULL without complaint. It's valid to pass NULL to
enable/disable/prepare/unprepare. Let's make use of this to simplify
things a tiny bit.
NOTE: th
In commit 58074b08c04a ("drm/bridge: ti-sn65dsi86: Read EDID blob over
DDC") we attempted to make the ti-sn65dsi86 bridge properly read the
EDID from the panel. That commit kinda worked but it had some serious
problems.
The problems all stem from the fact that userspace wants to be able to
read th
This patch is _only_ code motion to prepare for the patch
("drm/bridge: ti-sn65dsi86: Properly get the EDID, but only if
refclk") and make it easier to understand.
Signed-off-by: Douglas Anderson
---
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 196 +-
1 file changed, 98 inse
On Wednesday, 3 March 2021 9:08:15 AM AEDT Zi Yan wrote:
> On 26 Feb 2021, at 2:18, Alistair Popple wrote:
> > diff --git a/include/linux/rmap.h b/include/linux/rmap.h
> > index 7f1ee411bd7b..77fa17de51d7 100644
> > --- a/include/linux/rmap.h
> > +++ b/include/linux/rmap.h
> > @@ -86,8 +86,6 @@ st
Am 2021-03-01 um 10:09 a.m. schrieb Christian König:
> Am 27.02.21 um 04:45 schrieb Felix Kuehling:
>> Move fences that have already signaled should not prevent memory
>> allocations with no_wait_gpu.
>>
>> Signed-off-by: Felix Kuehling
>
> Reviewed-by: Christian König
I work on this on Alex's
Fix the warnings reported by kbot across MSM DP driver.
Reported-by: kernel test robot
Reported-by: Dan Carpenter
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/dp/dp_debug.c | 33 +
drivers/gpu/drm/msm/dp/dp_hpd.c | 4 ++--
drivers/gpu/drm/msm/dp/dp_po
While Kepler does technically support 256x256 cursors, it turns out that
Kepler actually has some additional requirements for scanout surfaces that
we're not enforcing correctly, which aren't present on Maxwell and later.
Cursor surfaces must always use small pages (4K), and overlay surfaces must
a
Hi Linus,
More may show up but this is what I have at this staged. These are
based on the commit in your tree where the swapfile issue is fixed,
and neither of the merged trees are in the bad area.
Otherwise just a single nouveau regression fix, and a bunch of amdgpu fixes.
Dave.
drm-fixes-2021
Hello Marek,
can't compile anything, here.
Poor Intel Nehalem X3470.
Trying LLVM 12-rc2 later.
Greetings,
Dieter
llvm-project/libclc> cd build && cmake ../
-- The CXX compiler identification is GNU 10.2.1
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for
The pull request you sent on Fri, 5 Mar 2021 12:50:16 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2021-03-05
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/280d542f6ffac0e6d65dc267f92191d509b13b64
Thank you!
--
Deet-doot-dot, I am a bot.
https://ko
[AMD Public Use]
Thanks. Reviewed-by: Evan Quan
-Original Message-
From: Jia-Ju Bai
Sent: Friday, March 5, 2021 11:54 AM
To: Deucher, Alexander ; Koenig, Christian
; airl...@linux.ie; dan...@ffwll.ch; Quan, Evan
; Zhang, Hawking ; Wang, Kevin(Yang)
; Gao, Likun
Cc: amd-...@lists.fr
Fix the following coccicheck warnings:
./drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c:8257:16-21: WARNING:
conversion to bool not needed here.
Reported-by: Abaci Robot
Signed-off-by: Jiapeng Chong
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 3 +--
1 file changed, 1 insertion(+
Maybe subject could be "Ignore debugfs failures, fix indentation, fix
logical error"?
Quoting Abhinav Kumar (2021-03-04 17:31:52)
> Fix the warnings reported by kbot across MSM DP driver.
Which warnings? Can you include them? Or at least list the three things
that are being fixed in this patch?
Hi John,
I love your patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v5.12-rc1]
[cannot apply to linux/master drm-intel/for-linux-next drm-tip/drm-tip
next-20210305]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And whe
On Thu, Mar 04, 2021 at 10:55:58PM -0800, Stephen Boyd wrote:
> > @@ -368,44 +368,21 @@ static int dp_debug_init(struct dp_debug *dp_debug,
> > struct drm_minor *minor)
> > int rc = 0;
> > struct dp_debug_private *debug = container_of(dp_debug,
> > struct dp
Am 05.03.21 um 02:21 schrieb Felix Kuehling:
Am 2021-03-01 um 10:09 a.m. schrieb Christian König:
Am 27.02.21 um 04:45 schrieb Felix Kuehling:
Move fences that have already signaled should not prevent memory
allocations with no_wait_gpu.
Signed-off-by: Felix Kuehling
Reviewed-by: Christian
67 matches
Mail list logo
