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 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
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
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
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
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
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
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 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
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
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(-)
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
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
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: 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 +
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
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
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
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
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
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
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
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 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
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 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
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).
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
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
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
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:
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
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
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:
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
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
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 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
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.
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
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),
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
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
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
---
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
---
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
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
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
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
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
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.
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!
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
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
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
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
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
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 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
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:
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
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
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
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
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
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()
>
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
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,
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
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 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.
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 +++---
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:
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
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
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 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")
>
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 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:
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
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
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 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
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
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
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
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 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 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
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
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
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 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
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
1 - 100 of 118 matches
Mail list logo
