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
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
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
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
---
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
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:
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
> >
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
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
>
Hi Dave & Daniel -
Sorry, late due to public holidays.
drm-intel-fixes-2021-05-14:
drm/i915 fixes for v5.13-rc2:
- Fix active callback alignment annotations and subsequent crashes
- Retract link training strategy to slow and wide, again
- Avoid division by zero on gen2
- Use correct width
[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
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
---
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
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
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:
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
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
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
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
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
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 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.
> 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.
>>
>>
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
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
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
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
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 '>struct_mutex'.
Locked on : 988
Unlocked on:
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
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
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
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
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
>
>
On Fri, May 14, 2021 at 1:32 PM Linus Torvalds
wrote:
>
> Another alternative would be to just delay the resize to when vcmode
> is put back to text mode again. That sounds somewhat reasonable to me,
> but it's a pretty big thing.
Actually thinking more about that option, it sounds horrible. It
From: Arnd Bergmann
This is one of the last drivers with a global init_module() function
instead of the modern module_init() annotation. Convert it over.
Signed-off-by: Arnd Bergmann
---
drivers/video/fbdev/matrox/matroxfb_base.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
Rob,
On 07/10/2020 03:10, benl-kernelpatc...@squareup.com wrote:
From: Benjamin Li
Take advantage of previously-added support for persisting PLL
registers across DSI PHY disable/enable cycles (see 328e1a6
'drm/msm/dsi: Save/Restore PLL status across PHY reset') to
support persisting across
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).
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
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
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
On 5/14/2021 2:30 PM, Arnd Bergmann wrote:
From: Arnd Bergmann
clang is a little overzealous with warning about a constant conversion
in an untaken branch of a ternary expression:
drivers/gpu/drm/msm/dsi/phy/dsi_phy_7nm.c:975:48: error: implicit conversion
from 'unsigned long long' to
As part of the System Managemenent Interface (SMI), use the HWMON
subsystem to display power utilization.
The following standard HWMON entries are currently supported
(and appropriately scaled):
/sys/class/drm/card0/device/hwmon/hwmon
- energy1_input
- power1_cap
-
drm/i915/dg1: Add HWMON power support
As part of the System Managemenent Interface (SMI), use the HWMON
subsystem to display power utilization.
The following standard HWMON entries are currently supported
(and appropriately scaled):
/sys/class/drm/card0/device/hwmon/hwmon
- energy1_input
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
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
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
From: Bhawanpreet Lakha
Due to the way displays and human vision work it is most effective to
encode luminance information in a non-linear space.
For SDR this non-linear mapping is assumed to roughly use a gamma 2.2 curve.
This was due to the way CRTs worked and was fine for SDR content with a
From: Bhawanpreet Lakha
Add color space definitions for BT601, BT709, BT2020, and DCI-P3.
Default to BT709, the sRGB color space.
Signed-off-by: Bhawanpreet Lakha
Signed-off-by: Harry Wentland
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 +
On Sat, 15 May 2021 at 00:31, Arnd Bergmann wrote:
>
> From: Arnd Bergmann
>
> clang is a little overzealous with warning about a constant conversion
> in an untaken branch of a ternary expression:
>
> drivers/gpu/drm/msm/dsi/phy/dsi_phy_7nm.c:975:48: error: implicit conversion
> from 'unsigned
ping?
thanks.
On 4/23/21 8:46 PM, Randy Dunlap wrote:
> DRM_RCAR_CMM depends on DRM_RCAR_DU. Since the following Kconfig
> symbols do not depend on DRM_RCAR_DU, the menu presentation is
> broken for the following R-Car Kconfig symbols.
>
> Use an if/endif block to make all of these symbols
ping?
thanks.
On 4/23/21 5:12 PM, Randy Dunlap wrote:
> When DRM_RCAR_DU=y and DRM_RCAR_LVDS=m, there are several build errors
> as reported by 'kernel test robot'. These can be corrected by changing
> source code occurrences of IS_ENABLED(...) to IS_REACHABLE(...).
>
> In looking at this, the
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
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
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
On Fri, May 14, 2021 at 11:27 PM Steven Price wrote:
> [snip]
> >>> Seems this version is ready to be applied if we get a review on the DT ?
> >>>
> >>> Mathias ? could you have a look ?
> >>>
> >>
> >> Given Rob has Acked the DT bindings, I think it's OK to apply patches
> >> 1, 3 and 4 via
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:
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
Applied. Thanks!
Alex
On Fri, May 14, 2021 at 3:18 AM Christian König
wrote:
>
> 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
From: Arnd Bergmann
clang is a little overzealous with warning about a constant conversion
in an untaken branch of a ternary expression:
drivers/gpu/drm/msm/dsi/phy/dsi_phy_7nm.c:975:48: error: implicit conversion
from 'unsigned long long' to 'unsigned long' changes value from 50 to
While we're taking a reference of the DDC adapter for a DP AUX channel in
tegra_sor_probe() because we're going to be using that adapter with the
SOR, now that we've moved where AUX registration happens the actual device
structure for the DDC adapter isn't initialized yet. Which means that we
On 2021/05/15 5:25, Maciej W. Rozycki wrote:
> NB for fbcon the usual ioctl to resize the console is FBIOPUT_VSCREENINFO
> rather than VT_RESIZEX; fbset(8) uses it, and I actually experimented with
> it and a TGA-like (SFB+) framebuffer when at my lab last time, as Linux is
> kind enough to
On 4/19/21 10:54 AM, Randy Dunlap wrote:
> On 4/19/21 10:10 AM, Randy Dunlap wrote:
>> On 4/19/21 2:01 AM, Robert Foss wrote:
>>> The DRM_SIL_SII8620 kconfig has a weak `imply` dependency
>>> on EXTCON, which causes issues when sii8620 is built
>>> as a builtin and EXTCON is built as a module.
>>>
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
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
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
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
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
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
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")
>
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.
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
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
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,
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
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
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:
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
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.
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
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
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 +++---
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()
>
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 '>struct_mutex'.
Locked on : 988
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
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
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
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
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
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
---
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
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
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
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),
1 - 100 of 118 matches
Mail list logo
