PTR_ERR should access the value just tested by IS_ERR, otherwise
the wrong error code will be returned.
Reported-by: Hulk Robot
Signed-off-by: Qiheng Lin
---
drivers/gpu/drm/bridge/ite-it66121.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/ite-it661
Am 14.05.21 um 08:40 schrieb Huacai Chen:
From: Yi Li
When PAGE_SIZE is larger than AMDGPU_PAGE_SIZE, the number of GPU TLB
entries which need to update in amdgpu_map_buffer() should be multiplied
by AMDGPU_GPU_PAGES_IN_CPU_PAGE (PAGE_SIZE / AMDGPU_PAGE_SIZE).
Signed-off-by: Yi Li
Signed-off-
[AMD Official Use Only - Internal Distribution Only]
We had entertained the idea of exposing the processes as sysfs nodes as you
proposed, but we had concerns about exposing process info in there, especially
since /proc already exists for that purpose.
I think if you were to follow that approac
In video/logo/pnmtologo.c, the function read_image can read from the
image file an integer 0 and pass it to function get_number255, leading
to a divide by zero problem.
Signed-off-by: Yiyuan GUO
---
drivers/video/logo/pnmtologo.c | 14 --
1 file changed, 12 insertions(+), 2 deletions
In function agp_3_5_enable from drivers/char/agp/isoch.c, the
variable ndevs may remain zero if all AGP devices have type of
"Bridge" or "Unclassified device". Passing ndevs==0 to function
agp_3_5_isochronous_node_enable or agp_3_5_nonisochronous_node_enable
will lead to divide by zero problems.
Tse
From: Yiyuan GUO
I guess it may only happen in theory, but maybe there is no harm in
adding a simple check?
Thanks.
From: Yi Li
When PAGE_SIZE is larger than AMDGPU_PAGE_SIZE, the number of GPU TLB
entries which need to update in amdgpu_map_buffer() should be multiplied
by AMDGPU_GPU_PAGES_IN_CPU_PAGE (PAGE_SIZE / AMDGPU_PAGE_SIZE).
Signed-off-by: Yi Li
Signed-off-by: Huacai Chen
---
drivers/gpu/drm/amd/am
On Wed, 12 May 2021 07:57:26 -0700
Rob Clark wrote:
> On Wed, May 12, 2021 at 1:23 AM Pekka Paalanen wrote:
> >
> > On Tue, 11 May 2021 18:44:17 +0200
> > Daniel Vetter wrote:
> >
> > > On Mon, May 10, 2021 at 12:06:05PM -0700, Rob Clark wrote:
> > > > On Mon, May 10, 2021 at 10:44 AM Danie
Well in my opinion exposing it through fdinfo turned out to be a really
clean approach.
It describes exactly the per file descriptor information we need.
Making that device driver independent is potentially useful as well.
Regards,
Christian.
Am 14.05.21 um 09:22 schrieb Nieto, David M:
[AM
Em Wed, 12 May 2021 18:07:04 +0100
David Woodhouse escreveu:
> On Wed, 2021-05-12 at 14:50 +0200, Mauro Carvalho Chehab wrote:
> > Such conversion tools - plus some text editor like LibreOffice or similar
> > - have
> > a set of rules that turns some typed ASCII characters into UTF-8
> > alte
In case of error, the function devm_ioremap() returns NULL pointer not
ERR_PTR().
The IS_ERR() test in the return value check should be replaced with NULL test.
After that, the error code -ENOMEM should be returned.
Reported-by: Hulk Robot
Signed-off-by: Qiheng Lin
---
drivers/gpu/drm/vmwgfx/v
On Fri, 2021-05-14 at 10:21 +0200, Mauro Carvalho Chehab wrote:
> Em Wed, 12 May 2021 18:07:04 +0100
> David Woodhouse escreveu:
>
> > On Wed, 2021-05-12 at 14:50 +0200, Mauro Carvalho Chehab wrote:
> > > Such conversion tools - plus some text editor like LibreOffice or
> > > similar - have
>
On Wed, May 12, 2021 at 2:19 AM Ville Syrjälä
wrote:
>
> On Mon, Apr 26, 2021 at 11:24:10PM +0800, Kai-Heng Feng wrote:
> > On HP Fury G7 Workstations, graphics output is re-routed from Intel GFX
> > to discrete GFX after S3. This is not desirable, because userspace will
> > treat connected displa
Hi, Chenyang,
Please make this patch and the other one in a series.
Huacai
On Fri, May 14, 2021 at 9:50 AM lichenyang wrote:
>
> Implement use GPIO and I2C driver to detect connector
> and fetch EDID via DDC.
>
> Signed-off-by: lichenyang
> ---
> drivers/gpu/drm/loongson/Makefile
While working on a drm driver that doesn't need the i2c algobit stuff I
noticed that DRM selects this code even tough only 8 drivers actually use
it. While also only some drivers use i2c, keep the select for I2C for the
next cleanup patch. Still prepare this already by also selecting I2C for
the in
On Wed, May 12, 2021 at 09:18:37PM +, Kasireddy, Vivek wrote:
> Hi Gerd,
>
> > > However, as part of this feature (explicit flush), I'd like to make the
> > > Guest wait until
> > > the current resource (as specified by resource_flush or set_scanout) is
> > > flushed or
> > > synchronized. B
From: Dillon Min
This seriese fix three i2c/clk bug for stm32 f4/f7
- kernel runing in sdram, i2c driver get data timeout
- ltdc clk turn off after kernel console active
- kernel hang in set ltdc clock rate
clk bug found on stm32f429/f469-disco board
Hi Patrice:
below is the guide to verify the
From: Dillon Min
This driver combine tiny/ili9341.c mipi_dbi_interface driver
with mipi_dpi_interface driver, can support ili9341 with serial
mode or parallel rgb interface mode by register configuration.
Reviewed-by: Linus Walleij
Link:
https://lore.kernel.org/lkml/1590378348-8115-7-git-send-
From: Dillon Min
As stm32f429's internal flash is 2Mbytes and compiled kernel
image bigger than 2Mbytes, so we have to load kernel image
to sdram on stm32f429-disco board which has 8Mbytes sdram space.
based on above context, as you knows kernel running on external
sdram is more slower than inte
From: Dillon Min
This is due to misuse ‘PLL_VCO_SAI' and'PLL_SAI' in clk-stm32f4.c
'PLL_SAI' is 2, 'PLL_VCO_SAI' is 7(defined in
include/dt-bindings/clock/stm32fx-clock.h).
'post_div' point to 'post_div_data[]', 'post_div->pll_num'
is PLL_I2S or PLL_SAI.
'clks[PLL_VCO_SAI]' has valid 'struct cl
From: Dillon Min
stm32's clk driver register two ltdc gate clk to clk core by
clk_hw_register_gate() and clk_hw_register_composite()
first: 'stm32f429_gates[]', clk name is 'ltdc', which no user to use.
second: 'stm32f429_aux_clk[]', clk name is 'lcd-tft', used by ltdc driver
both of them point
On 06/05/2021 20:13, Matthew Brost wrote:
Basic GuC submission support. This is the first bullet point in the
upstreaming plan covered in the following RFC [1].
At a very high level the GuC is a piece of firmware which sits between
the i915 and the GPU. It offloads some of the scheduling of co
On Fri, 07 May 2021, Lyude Paul wrote:
> On Fri, 2021-05-07 at 17:00 -0500, Bjorn Andersson wrote:
>> On Fri 07 May 16:18 CDT 2021, Lyude Paul wrote:
>>
>> > Adding ville from Intel to also get their take on this.
>> >
>> > In general we've been trying to move DRM to a design where we don't expo
> On Fri, 2021-05-14 at 10:21 +0200, Mauro Carvalho Chehab wrote:
>> I do use a lot of UTF-8 here, as I type texts in Portuguese, but I rely
>> on the US-intl keyboard settings, that allow me to type as "'a" for á.
>> However, there's no shortcut for non-Latin UTF-codes, as far as I know.
>>
>> So,
On Fri, Apr 16, 2021 at 05:42:04PM +0300, Andy Shevchenko wrote:
> +Cc: Greg.
>
> Greg, can you pick up this one?
>
> The subsystem seems orphaned and I see your name in the git history for the
> recent submissions against that driver.
Now applied, thanks.
greg k-h
Hi
Am 14.05.21 um 03:53 schrieb Stephen Rothwell:
Hi all,
On Fri, 30 Apr 2021 08:23:21 +1000 Stephen Rothwell
wrote:
On Thu, 18 Mar 2021 12:52:41 +1100 Stephen Rothwell
wrote:
On Wed, 17 Mar 2021 14:08:24 +1100 Stephen Rothwell
wrote:
Today's linux-next merge of the drm-intel tree g
Maxime Ripard 于2021年4月30日周五 下午5:22写道：
>
> On Sun, Apr 25, 2021 at 08:36:05PM +0800, Kevin Tang wrote:
> > Adds DPU(Display Processor Unit) support for the Unisoc's display
> > subsystem.
> > It's support multi planes, scaler, rotation, PQ(Picture Quality) and more.
> >
> > v2:
> > - Use drm_xxx
On Thu, May 13, 2021 at 01:07:56PM +0100, Matthew Auld wrote:
> From: Chris Wilson
>
> When instantiating a tiled object on an L-shaped memory machine, we mark
> the object as unshrinkable to prevent the shrinker from trying to swap
> out the pages. We have to do this as we do not know the swizzl
On 14/05/2021 09:04, Christian König wrote:
Well in my opinion exposing it through fdinfo turned out to be a really
clean approach.
It describes exactly the per file descriptor information we need.
Yeah fdinfo certainly is mostly simple and neat.
I say mostly because main problem I see wit
David also said that you considered sysfs but were wary of exposing
process info in there. To clarify, my patch is not exposing sysfs
entry per process, but one per open drm fd.
Yes, we discussed this as well, but then rejected the approach.
To have useful information related to the open d
From: Arnd Bergmann
gcc points out an invalid bit shift operation on 32-bit architectures
with 64-bit dma_addr_t:
drivers/gpu/drm/tegra/hub.c: In function 'tegra_shared_plane_atomic_update':
include/vdso/bits.h:7:40: error: left shift count >= width of type
[-Werror=shift-count-overflow]
7
Hello Joseph Kogut,
The patch 70556e24e18e: "drm: remove usage of drm_pci_alloc/free"
from Apr 22, 2021, leads to the following static checker warning:
drivers/gpu/drm/drm_bufs.c:1090 drm_legacy_addbufs_pci()
warn: inconsistent returns '&dev->struct_mutex'.
Locked on : 988
Un
On Wed, May 5, 2021 at 11:11 PM wrote:
>
> On 2021-04-08 20:33, Rob Herring wrote:
> > On Mon, Apr 05, 2021 at 04:36:08PM +0530, Krishna Manikandan wrote:
> >> Add YAML schema for the device tree bindings for DSI
> >> + data-lanes:
> >> +$ref: "/schemas/media/video-in
Em Fri, 14 May 2021 12:08:36 +0100
Edward Cree escreveu:
> For anyone who doesn't know about it: X has this wonderful thing called
> the Compose key[1]. For instance, type ⎄--- to get —, or ⎄<" for “.
> Much more mnemonic than Unicode codepoints; and you can extend it with
> user-defined seque
On Wed, May 12, 2021 at 08:56:09PM +0100, Colin King wrote:
> From: Colin Ian King
>
> In the case where fifo->static_buffer fails to be allocated the
> error return path neglects to kfree the fifo object. Fix this by
> adding in the missing kfree.
>
> Addresses-Coverity: ("Resource leak")
> Fix
On 14/05/2021 15:30, Dan Carpenter wrote:
> On Wed, May 12, 2021 at 08:56:09PM +0100, Colin King wrote:
>> From: Colin Ian King
>>
>> In the case where fifo->static_buffer fails to be allocated the
>> error return path neglects to kfree the fifo object. Fix this by
>> adding in the missing kfree.
On Fri, May 14, 2021 at 12:54 AM Pekka Paalanen wrote:
>
> On Wed, 12 May 2021 07:57:26 -0700
> Rob Clark wrote:
>
> > On Wed, May 12, 2021 at 1:23 AM Pekka Paalanen wrote:
> > >
> > > On Tue, 11 May 2021 18:44:17 +0200
> > > Daniel Vetter wrote:
> > >
> > > > On Mon, May 10, 2021 at 12:06:05PM
Ping
Andrey
On 2021-05-12 10:26 a.m., Andrey Grodzovsky wrote:
Handle all DMA IOMMU gropup related dependencies before the
group is removed.
v5: Drop IOMMU notifier and switch to lockless call to ttm_tt_unpopulate
v6: Drop the BO unamp list
v7:
Drop amdgpu_gart_fini
In amdgpu_ih_ring_fini do u
Ping
Andrey
On 2021-05-12 10:26 a.m., Andrey Grodzovsky wrote:
If removing while commands in flight you cannot wait to flush the
HW fences on a ring since the device is gone.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c | 16 ++--
1 file change
Ping
Andrey
On 2021-05-12 10:26 a.m., Andrey Grodzovsky wrote:
Access to those must be prevented post pci_remove
v6: Drop BOs list, unampping VRAM BAR is enough.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 24 +++---
drivers/gpu/drm/am
On 14/05/2021 14:53, Christian König wrote:
David also said that you considered sysfs but were wary of exposing
process info in there. To clarify, my patch is not exposing sysfs
entry per process, but one per open drm fd.
Yes, we discussed this as well, but then rejected the approach.
T
On 13/05/2021 16:55, Ezequiel Garcia wrote:
> Hi Neil,
>
> On Mon, 26 Apr 2021 at 06:59, Neil Armstrong wrote:
>>
>> Hi,
>>
>> On 21/04/2021 07:28, Nicolas Boichat wrote:
>>> Hi!
>>>
>>> This is just a rebase of the v11, untested (but it seems like
>>> Neil Armstrong recently tested it), with sma
From: Colin Ian King
The allocation of fifo is lacking an allocation failure check, so
fix this by adding one.
In the case where fifo->static_buffer fails to be allocated the
error return path neglects to kfree the fifo object. Fix this by
adding in the missing kfree.
Kudos to Dan Carpenter for
Am 14.05.21 um 16:47 schrieb Tvrtko Ursulin:
On 14/05/2021 14:53, Christian König wrote:
David also said that you considered sysfs but were wary of exposing
process info in there. To clarify, my patch is not exposing sysfs
entry per process, but one per open drm fd.
Yes, we discussed thi
On 14/05/2021 15:56, Christian König wrote:
Am 14.05.21 um 16:47 schrieb Tvrtko Ursulin:
On 14/05/2021 14:53, Christian König wrote:
David also said that you considered sysfs but were wary of exposing
process info in there. To clarify, my patch is not exposing sysfs
entry per process, but
Am 14.05.21 um 17:03 schrieb Tvrtko Ursulin:
On 14/05/2021 15:56, Christian König wrote:
Am 14.05.21 um 16:47 schrieb Tvrtko Ursulin:
On 14/05/2021 14:53, Christian König wrote:
David also said that you considered sysfs but were wary of
exposing process info in there. To clarify, my patch
Hi Dan,
On Fri, May 14, 2021 at 6:54 AM Dan Carpenter wrote:
>
> Hello Joseph Kogut,
>
> The patch 70556e24e18e: "drm: remove usage of drm_pci_alloc/free"
> from Apr 22, 2021, leads to the following static checker warning:
>
> drivers/gpu/drm/drm_bufs.c:1090 drm_legacy_addbufs_pci()
> war
On 14/05/2021 15:48, Neil Armstrong wrote:
> On 13/05/2021 16:55, Ezequiel Garcia wrote:
>> Hi Neil,
>>
>> On Mon, 26 Apr 2021 at 06:59, Neil Armstrong wrote:
>>>
>>> Hi,
>>>
>>> On 21/04/2021 07:28, Nicolas Boichat wrote:
Hi!
This is just a rebase of the v11, untested (but it seems
syzbot is reporting that a local user with the framebuffer console can
crash the kernel [1], for ioctl(VT_RESIZE) allows a TTY to set arbitrary
rows/columns values regardless of amount of memory reserved for
the graphical screen.
--
#include
#include
#include
#include
#include
#includ
Maybe this patch needs a better explanation how the GART and IH changes
relate to IOMMU or what's the problem this is meant to fix. Just looking
at the patch I don't see the connection. Looks like just a bunch of
refactoring to me.
Regards,
Felix
Am 2021-05-14 um 10:41 a.m. schrieb Andrey Grod
Makes sense - will update.
Andrey
On 2021-05-14 12:25 p.m., Felix Kuehling wrote:
Maybe this patch needs a better explanation how the GART and IH changes
relate to IOMMU or what's the problem this is meant to fix. Just looking
at the patch I don't see the connection. Looks like just a bunch of
Pulling a few threads together...
On Mon, May 10, 2021 at 1:39 PM Francisco Jerez wrote:
>
> I agree with Martin on this. Given that using GuC currently involves
> making your open-source graphics stack rely on a closed-source
> cryptographically-protected blob in order to submit commands to the
On Fri, May 14, 2021 at 8:13 AM Joseph Kogut wrote:
>
> Hi Dan,
>
> On Fri, May 14, 2021 at 6:54 AM Dan Carpenter
> wrote:
> >
> > Hello Joseph Kogut,
> >
> > The patch 70556e24e18e: "drm: remove usage of drm_pci_alloc/free"
> > from Apr 22, 2021, leads to the following static checker warning:
>
On Fri, May 14, 2021 at 6:12 AM Tvrtko Ursulin
wrote:
>
> On 06/05/2021 20:13, Matthew Brost wrote:
> > Basic GuC submission support. This is the first bullet point in the
> > upstreaming plan covered in the following RFC [1].
> >
> > At a very high level the GuC is a piece of firmware which sits
Hello.
On Fri, May 14, 2021 at 10:24:26AM +0200, Thomas Stein wrote:
> After upgrading to linux 5.12 the display on my X1 Carbon Gen 2 starts to
> flicker. Well actually it seems to turn off and on again and again. Here a
> link to a video a person posted who has the same issue as me obviousely.
On Fri, May 14, 2021 at 12:11:56PM +0100, Tvrtko Ursulin wrote:
>
> On 06/05/2021 20:13, Matthew Brost wrote:
> > Basic GuC submission support. This is the first bullet point in the
> > upstreaming plan covered in the following RFC [1].
> >
> > At a very high level the GuC is a piece of firmware
On Fri, May 14, 2021 at 11:36:37AM -0500, Jason Ekstrand wrote:
> On Fri, May 14, 2021 at 6:12 AM Tvrtko Ursulin
> wrote:
> >
> > On 06/05/2021 20:13, Matthew Brost wrote:
> > > Basic GuC submission support. This is the first bullet point in the
> > > upstreaming plan covered in the following RFC
Am 13.05.21 um 14:29 schrieb Paul Cercueil:
Hi,
Almost two months later,
Le mar., mars 23 2021 at 14:40:08 +, Paul Cercueil
a écrit :
When using a 24-bit panel on a 8-bit serial bus, the pixel clock
requested by the panel has to be multiplied by 3, since the subpixels
are shifted sequ
On Fri, May 14, 2021 at 9:20 AM Tetsuo Handa
wrote:
>
> Currently it is impossible to control upper limit of rows/columns values
> based on amount of memory reserved for the graphical screen, for
> resize_screen() calls vc->vc_sw->con_resize() only if vc->vc_mode is not
> already KD_GRAPHICS
Hone
On Fri, May 14, 2021 at 10:29 AM Linus Torvalds
wrote:
>
> So why not just say "that clearly already doesn't work, so make it
> explicitly not permitted"?
IOW, something like this would seem fairly simple and straightforward:
diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index 01645
On Thu, May 13, 2021 at 7:34 PM Dave Airlie wrote:
>
> Just realised I got the tag header wrong, these are the rc2 fixes.
Heh. The tag message also says:
> vc4:
> - drop an used function
which just makes me think you may have started drinking early ;)
I fixed it up. Skål!
Lin
The pull request you sent on Fri, 14 May 2021 12:34:38 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2021-05-14
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/b5304a4f9ad88a712c26c63691a99c0b9b1b5dc6
Thank you!
--
Deet-doot-dot, I am a bot.
https://k
On Tue, May 4, 2021 at 3:47 AM Daniel Vetter wrote:
>
> On Mon, May 03, 2021 at 10:57:23AM -0500, Jason Ekstrand wrote:
> > Previously, we were storing the ring size in the ring pointer before it
> > was actually allocated. We would then guard setting the ring size on
> > checking for CONTEXT_ALL
On Tue, May 4, 2021 at 3:50 AM Daniel Vetter wrote:
>
> On Mon, May 03, 2021 at 10:57:27AM -0500, Jason Ekstrand wrote:
> > This API allows one context to grab bits out of another context upon
> > creation. It can be used as a short-cut for setparam(getparam()) for
> > things like I915_CONTEXT_PA
This series:
* Cleans up i915's DPCD backlight code a little bit
* Extracts i915's DPCD backlight code into a set of shared DRM helpers
* Starts using those helpers in nouveau to add support to nouveau for
DPCD backlight control
v2 series-wide changes:
* Rebase
v3 series-wide changes:
* Split up
This is kind of an annoying aspect of DRM's DP helpers:
drm_dp_dpcd_readb/writeb() return the size of bytes read/written on
success, thus we want to check against that instead of checking if the
return value is less than 0.
I'll probably be fixing this in the near future once I start doing DP work
Noticed this while moving all of the VESA backlight code in i915 over to
DRM helpers: it would appear that we calculate the frequency value we want
to write to DP_EDP_BACKLIGHT_FREQ_SET twice even though this value never
actually changes during runtime. So, let's simplify things by just caching
thi
Get rid of the extraneous switch case in here, and just open code
edp_backlight_mode as we only ever use it once.
v4:
* Check that backlight mode is DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD, not
DP_EDP_BACKLIGHT_CONTROL_MODE_MASK - imirkin
Signed-off-by: Lyude Paul
Reviewed-by: Rodrigo Vivi
---
..
Also, stop printing the DPCD register that failed, and just describe it
instead. Saves us from having to look up each register offset when reading
through kernel logs (plus, DPCD dumping with drm.debug |= 0x100 will give
us that anyway).
Signed-off-by: Lyude Paul
Reviewed-by: Rodrigo Vivi
---
.
Since we're about to implement eDP backlight support in nouveau using the
standard protocol from VESA, we might as well just take the code that's
already written for this and move it into a set of shared DRM helpers.
Note that these helpers are intended to handle DPCD related backlight
control bit
Since we're about to be moving this code into shared DRM helpers, we might
as well start to cache certain backlight capabilities that can be
determined from the EDP DPCD, and are likely to be relevant to the majority
of drivers using said helpers. The main purpose of this is just to prevent
every d
This adds support for controlling panel backlights over eDP using VESA's
standard backlight control interface. Luckily, Nvidia was cool enough to
never come up with their own proprietary backlight control interface (at
least, not any that I or the laptop manufacturers I've talked to are aware
of),
No functional changes, just move set_vesa_backlight_enable() closer to it's
only caller: intel_dp_aux_vesa_enable_backlight().
Signed-off-by: Lyude Paul
Reviewed-by: Rodrigo Vivi
---
.../drm/i915/display/intel_dp_aux_backlight.c | 54 +--
1 file changed, 27 insertions(+), 27 del
If we can't read DP_EDP_PWMGEN_BIT_COUNT in
intel_dp_aux_vesa_calc_max_backlight() but do have a valid PWM frequency
defined in the VBT, we'll keep going in the function until we inevitably
fail on reading DP_EDP_PWMGEN_BIT_COUNT_CAP_MIN. There's not much point in
doing this, so just return early.
On Tue, May 4, 2021 at 3:56 AM Daniel Vetter wrote:
>
> On Mon, May 03, 2021 at 10:57:31AM -0500, Jason Ekstrand wrote:
> > Even though FENCE_SUBMIT is only documented to wait until the request in
> > the in-fence starts instead of waiting until it completes, it has a bit
> > more magic than that.
On Tue, May 4, 2021 at 11:17 AM Daniel Vetter wrote:
>
> On Mon, May 03, 2021 at 10:57:38AM -0500, Jason Ekstrand wrote:
> > Since free_engines works for partially constructed engine sets, we can
> > use the usual goto pattern.
> >
> > Signed-off-by: Jason Ekstrand
>
> I guess subsequent patches
On Fri, May 14, 2021 at 10:37 AM Linus Torvalds
wrote:
>
> IOW, something like this would seem fairly simple and straightforward:
Proper patch in case syzbot can test this..
Linus
From b33ca195cecea478768de353b3ae976c07a65615 Mon Sep 17 00:00:00 2001
From: Linus Torvalds
Date:
On 5/14/21 10:49 AM, Colin King wrote:
From: Colin Ian King
The allocation of fifo is lacking an allocation failure check, so
fix this by adding one.
In the case where fifo->static_buffer fails to be allocated the
error return path neglects to kfree the fifo object. Fix this by
adding in the m
On 5/14/21 4:28 AM, Qiheng Lin wrote:
In case of error, the function devm_ioremap() returns NULL pointer not
ERR_PTR().
The IS_ERR() test in the return value check should be replaced with NULL test.
After that, the error code -ENOMEM should be returned.
Reported-by: Hulk Robot
Signed-off-by: Q
On Tue, May 4, 2021 at 3:33 PM Daniel Vetter wrote:
>
> On Mon, May 03, 2021 at 10:57:40AM -0500, Jason Ekstrand wrote:
> > This means that the proto-context needs to grow support for engine
> > configuration information as well as setparam logic. Fortunately, we'll
> > be deleting a lot of setpa
On Sun, May 9, 2021 at 4:21 PM Rob Clark wrote:
>
> Hi Dave & Daniel,
>
> First round of fixes for v5.13
>
> The following changes since commit a29c8c0241654d5f3165d52e9307e4feff955621:
>
> drm/msm/disp/dpu1: fix display underruns during modeset. (2021-04-09
> 12:02:35 -0700)
>
> are available i
Hi Dave & Daniel,
First round of fixes for v5.13
The following changes since commit a29c8c0241654d5f3165d52e9307e4feff955621:
drm/msm/disp/dpu1: fix display underruns during modeset. (2021-04-09
12:02:35 -0700)
are available in the Git repository at:
https://gitlab.freedesktop.org/drm/msm.
oRework of my previous patchset which added support for GEM buffers
backed by non-coherent memory to the ingenic-drm driver.
Having GEM buffers backed by non-coherent memory is interesting in
the particular case where it is faster to render to a non-coherent
buffer then sync the data cache, than t
Having GEM buffers backed by non-coherent memory is interesting in the
particular case where it is faster to render to a non-coherent buffer
then sync the data cache, than to render to a write-combine buffer, and
(by extension) much faster than using a shadow buffer. This is true for
instance on so
This function can be used by drivers that use damage clips and have
CMA GEM objects backed by non-coherent memory. Calling this function
in a plane's .atomic_update ensures that all the data in the backing
memory have been written to RAM.
v3: - Only sync data if using GEM objects backed by non-coh
With the module parameter ingenic-drm.cached_gem_buffers, it is possible
to specify that we want GEM buffers backed by non-coherent memory.
This dramatically speeds up software rendering on Ingenic SoCs, even for
tasks where write-combine memory should in theory be faster (e.g. simple
blits).
Ena
On Wed, May 12, 2021 at 10:34:59AM +0200, Daniel Vetter wrote:
> On Tue, May 11, 2021 at 11:44:28AM -0700, Matthew Brost wrote:
> > On Tue, May 11, 2021 at 05:11:44PM +0200, Daniel Vetter wrote:
> > > On Thu, May 06, 2021 at 10:30:48AM -0700, Matthew Brost wrote:
> > > > i915_drm.h updates for 'set
On Fri, 14 May 2021, Linus Torvalds wrote:
> > Currently it is impossible to control upper limit of rows/columns values
> > based on amount of memory reserved for the graphical screen, for
> > resize_screen() calls vc->vc_sw->con_resize() only if vc->vc_mode is not
> > already KD_GRAPHICS
>
> Hon
On Fri, May 14, 2021 at 1:25 PM Maciej W. Rozycki wrote:
>
> Overall I think it does make sense to resize the text console at any
> time, even if the visible console (VT) chosen is in the graphics mode,
It might make sense, but only if we call the function to update the
low-level data.
Not call
The patch 70556e24e18e: "drm: remove usage of drm_pci_alloc/free" leads
to the following static checker warning:
drivers/gpu/drm/drm_bufs.c:1090 drm_legacy_addbufs_pci()
warn: inconsistent returns '&dev->struct_mutex'.
Locked on : 988
Unlocked on: 938,944,951,959,973,1005,1042
On 2021-04-30 6:39 a.m., Shashank Sharma wrote:
> Hello Pekka,
>
> On 30/04/21 15:13, Pekka Paalanen wrote:
>> On Wed, 28 Apr 2021 13:24:27 +0530
>> Shashank Sharma wrote:
>>
>>> Assuming these details, A compositor will look for DRM color properties
>>> like these:
>>>
>>> 1. Degamma plane p
Hey,
Looks like I wasn't the only one not fully switched on this week, the
msm pull has a missing tag so I missed it, and i915 team were a bit
late. In my defence I did have a day with the roof of my home office
removed, so was sitting at my kids desk.
Dave.
drm-fixes-2021-05-15:
drm fixes for 5
On 2021-04-30 8:53 p.m., Sebastian Wick wrote:
> On 2021-04-26 20:56, Harry Wentland wrote:
>> On 2021-04-26 2:07 p.m., Ville Syrjälä wrote:
>>> On Mon, Apr 26, 2021 at 01:38:50PM -0400, Harry Wentland wrote:
From: Bhawanpreet Lakha
Add the following color encodings
- RGB ve
On 2021-04-27 10:50 a.m., Pekka Paalanen wrote:
> On Mon, 26 Apr 2021 13:38:49 -0400
> Harry Wentland wrote:
>
>> ## Introduction
>>
>> We are looking to enable HDR support for a couple of single-plane and
>> multi-plane scenarios. To do this effectively we recommend new
>> interfaces to drm_plan
We are looking to enable HDR support for a couple of single-plane and
multi-plane scenarios. To do this effectively we recommend new interfaces
to drm_plane. The first patch gives a bit of background on HDR and why we
propose these interfaces.
v2:
* Moved RFC from cover letter to kernel doc (Dani
Use the new DRM RFC doc section to capture the RFC previously only
described in the cover letter at
https://patchwork.freedesktop.org/series/89506/
Update the RFC based on feedback received:
* don't use color_encoding property to define color space
* expand on reason for SDR luminance definition
From: Bhawanpreet Lakha
SDR is typically mastered at 200 nits and HDR is mastered at up to 10,000
nits. Due to this luminance range difference if we blend a SDR and
HDR plane together, we can run into problems where the HDR plane is too
bright or the SDR plane is too dim
A common solution to thi
We currently have 1D LUTs to define output transfer function but using a
1D LUT is not always the best way to define a transfer function for HW
that has ROMs for certain transfer functions, or for HW that has complex
PWL definition for accurate LUT definitions.
For this reason we're introducing na
Show the CSC matrixes in a 4x3 format.
Signed-off-by: Harry Wentland
---
drivers/gpu/drm/amd/display/dc/inc/hw/dpp.h | 28 +
1 file changed, 18 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/inc/hw/dpp.h
b/drivers/gpu/drm/amd/display/dc/inc/hw/dp
1 - 100 of 117 matches
Mail list logo
