If the kmemdup() fails then this should return a negative error code
but it currently returns success
Fixes: b4a7db71ea06 ("drm/amdgpu: add per device user friendly xgmi events for
vega20")
Signed-off-by: Dan Carpenter
---
v2: I sent this patch in Feb but I accidentally added an unrelated
hunk
If nouveau_get_backlight_name() fails then this should return -ENOMEM
but currently it returns success.
Fixes: db1a0ae21461 ("drm/nouveau/bl: Assign different names to interfaces")
Signed-off-by: Dan Carpenter
---
This is from static analysis. In the original commit db1a0ae21461
Hi, Zack,
On 4/13/21 10:59 PM, Zack Rusin wrote:
During cotable resize we pin the backup buffer to make sure the
trylock doesn't fail. We were never unpinning the backup buffer
resulting in every subsequent cotable resize trying to release a
pinned bo. After we copy the old backup to the new we
Quoting Kuogee Hsieh (2021-04-13 16:11:30)
> At dongle unplug, dp initializes audio_comp followed by sending disconnect
> event notification to audio and to make sure audio had shutdown completely
> by wait for audio completion notification at display_disable(). This patch
Is this
Quoting Kuogee Hsieh (2021-04-13 16:11:10)
> Link status is different from display connected status in the case
> of something like an Apple dongle where the type-c plug can be
> connected, and therefore the link is connected, but no sink is
> connected until an HDMI cable is plugged into the
Hi Daniel,
On Tue, 2021-04-13 at 16:14 +0200, Lucas Stach wrote:
> Am Dienstag, dem 13.04.2021 um 16:04 +0200 schrieb Daniel Vetter:
> > On Tue, Apr 13, 2021 at 01:47:28PM +0200, Lucas Stach wrote:
> > > Am Dienstag, dem 13.04.2021 um 11:48 +0200 schrieb Daniel Vetter:
> > > > Since
> > > >
> >
On Wed, 2021-04-14 at 07:38 +0800, Chun-Kuang Hu wrote:
> Hi, Yongqiang:
>
> Yongqiang Niu 於 2021年4月12日 週一 下午7:19寫道：
> >
> > This reverts commit f83b03fc727ab56a77e68713d6e40299698f3c9f.
> >
> > Signed-off-by: Yongqiang Niu
> > ---
> > Documentation/devicetree/bindings/mailbox/mtk-gce.txt | 2
Hi, Yongqiang:
Yongqiang Niu 於 2021年4月12日 週一 下午7:19寫道：
>
> This reverts commit f83b03fc727ab56a77e68713d6e40299698f3c9f.
>
> Signed-off-by: Yongqiang Niu
> ---
> Documentation/devicetree/bindings/mailbox/mtk-gce.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git
Make sure main link is in connection state before start aux
read/write operation to avoid unnecessary long delay due to
main link had been unplugged.
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/dp/dp_aux.c | 5 +
drivers/gpu/drm/msm/dp/dp_link.c | 20 +++-
2 files
At dongle unplug, dp initializes audio_comp followed by sending disconnect
event notification to audio and to make sure audio had shutdown completely
by wait for audio completion notification at display_disable(). This patch
will not re initialize audio_comp at display_disable() if audio shutdown
Link status is different from display connected status in the case
of something like an Apple dongle where the type-c plug can be
connected, and therefore the link is connected, but no sink is
connected until an HDMI cable is plugged into the dongle.
The sink_count of DPCD of dongle will increase
On Tue, Apr 13, 2021 at 2:37 PM Daniel Vetter wrote:
>
> On Tue, Apr 13, 2021 at 8:02 PM Alex Deucher wrote:
> >
> > On Tue, Apr 13, 2021 at 1:05 PM Kai-Heng Feng
> > wrote:
> > >
> > > On some platforms like Hyper-V and RPi4 with UEFI firmware, efifb is not
> > > a PCI device.
> > >
> > > So
On Sun, Apr 11, 2021 at 05:53:32PM -0700, Rob Clark wrote:
> Hi Dave,
>
> This time around a bit larger than usual, but a large part of that is
> Dmitry's dsi phy/pll refactor (which is itself a pretty large negative
> diffstat). The dsi phy/pll refactor includes a couple clk patches a-b
> the
On Mon, Apr 12, 2021 at 06:07:32PM -0400, Alex Deucher wrote:
> Hi Dave, Daniel,
>
> Same PR as last week plus a few accumulated fixes, rebased on drm-next
> to resolve the dependencies between ttm and scheduler with changes in amdgpu.
>
> The following changes since commit
During cotable resize we pin the backup buffer to make sure the
trylock doesn't fail. We were never unpinning the backup buffer
resulting in every subsequent cotable resize trying to release a
pinned bo. After we copy the old backup to the new we can release
the pin.
Mob's are always pinned so we
Hi Neil,
I get build failures locally:
drivers/gpu/drm/bridge/ite-it66121.c: In function
‘it66121_hw_reset’:
drivers/gpu/drm/bridge/ite-it66121.c:242:2: error: implicit declaration
of function ‘gpiod_set_value’
[-Werror=implicit-function-declaration]
242 | gpiod_set_value(ctx->gpio_reset,
Hey Neil & Phong,
Thanks for submitting this series!
> +
> +static const struct drm_bridge_funcs it66121_bridge_funcs = {
> + .attach = it66121_bridge_attach,
> + .enable = it66121_bridge_enable,
> + .disable = it66121_bridge_disable,
> + .mode_set =
Hi Paul,
On Tue, Apr 13, 2021 at 07:09:17PM +0100, Paul Cercueil wrote:
> Le lun. 12 avril 2021 à 17:46, Neil Armstrong a écrit :
> > From: Phong LE
> >
> > Add the ITE bridge HDMI it66121 bindings.
> >
> > Signed-off-by: Phong LE
> > Signed-off-by: Neil Armstrong
> > ---
> >
On Tue, Apr 13, 2021 at 8:02 PM Alex Deucher wrote:
>
> On Tue, Apr 13, 2021 at 1:05 PM Kai-Heng Feng
> wrote:
> >
> > On some platforms like Hyper-V and RPi4 with UEFI firmware, efifb is not
> > a PCI device.
> >
> > So make sure efifb_pci_dev is found before using it.
> >
> > Fixes:
Hi Neil,
Le lun. 12 avril 2021 à 17:46, Neil Armstrong
a écrit :
From: Phong LE
Add the ITE bridge HDMI it66121 bindings.
Signed-off-by: Phong LE
Signed-off-by: Neil Armstrong
---
.../bindings/display/bridge/ite,it66121.yaml | 123
++
1 file changed, 123 insertions(+)
On Tue, Apr 13, 2021 at 1:05 PM Kai-Heng Feng
wrote:
>
> On some platforms like Hyper-V and RPi4 with UEFI firmware, efifb is not
> a PCI device.
>
> So make sure efifb_pci_dev is found before using it.
>
> Fixes: a6c0fd3d5a8b ("efifb: Ensure graphics device for efifb stays at PCI
> D0")
>
On Mon, 12 Apr 2021 at 17:47, Neil Armstrong wrote:
>
> On 12/04/2021 17:46, Neil Armstrong wrote:
> > From: Phong LE
> >
> > Add Neil Armstrong and myself as maintainers
> >
> > Signed-off-by: Phong LE
>
> Obviously:
> Signed-off-by: Neil Armstrong
>
> > ---
> > MAINTAINERS | 8
> >
On some platforms like Hyper-V and RPi4 with UEFI firmware, efifb is not
a PCI device.
So make sure efifb_pci_dev is found before using it.
Fixes: a6c0fd3d5a8b ("efifb: Ensure graphics device for efifb stays at PCI D0")
BugLink: https://bugs.launchpad.net/bugs/1922403
Signed-off-by: Kai-Heng
Hey Randy,
Thanks for looking at this!
On Fri, 9 Apr 2021 at 18:38, Randy Dunlap wrote:
>
> On 4/8/21 6:07 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
On Tue, Apr 13, 2021 at 05:02:40PM +0800, Jisheng Zhang wrote:
> I met below error during boot with i915 builtin if pass
> "i915.mitigations=off":
> [0.015589] Booting kernel: `off' invalid for parameter `i915.mitigations'
>
> The reason is slab subsystem isn't ready at that time, so
On Tue, 13 Apr 2021 at 14:53, Christian König
wrote:
>
> No functional changes, just removing the leftovers from the redesign.
>
> Signed-off-by: Christian König
Reviewed-by: Matthew Auld
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
On Tue, 13 Apr 2021 at 14:52, Christian König
wrote:
>
> Drop some ussage of mem in the code.
usage
>
> Signed-off-by: Christian König
Reviewed-by: Matthew Auld
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
Hi Neil,
Thank you for the patch.
On Mon, Apr 12, 2021 at 05:46:46PM +0200, Neil Armstrong wrote:
> From: Phong LE
>
> Add the ITE bridge HDMI it66121 bindings.
>
> Signed-off-by: Phong LE
> Signed-off-by: Neil Armstrong
> ---
> .../bindings/display/bridge/ite,it66121.yaml | 123
On Tue, 13 Apr 2021 at 14:52, Christian König
wrote:
>
> Change a couple of cases where it makes more sense to use the base size
> instead of the number of pages in the resource.
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/nouveau/nouveau_bo.c| 9 -
>
On Tuesday, April 13th, 2021 at 11:49 AM, Daniel Vetter
wrote:
> + * Note that userspace can check the DRM_CAP_ADDFB2_MODIFIERS driver
Prepend an ampersand like so and a hyperlink will be rendered:
Note that userspace can check the _CAP_ADDFB2_MODIFIERS driver
On Mon, 12 Apr 2021 17:46:46 +0200, Neil Armstrong wrote:
> From: Phong LE
>
> Add the ITE bridge HDMI it66121 bindings.
>
> Signed-off-by: Phong LE
> Signed-off-by: Neil Armstrong
> ---
> .../bindings/display/bridge/ite,it66121.yaml | 123 ++
> 1 file changed, 123
The vc4_set_crtc_possible_masks is meant to run over all the encoders
and then set their possible_crtcs mask to their associated pixelvalve.
However, since the commit 39fcb2808376 ("drm/vc4: txp: Turn the TXP into
a CRTC of its own"), the TXP has been turned to a CRTC and encoder of
its own, and
The HDMI controller on the BCM2711 includes a scrambler in order to
reach the HDMI 2.0 modes that require it. Let's add the support for it.
Acked-by: Thomas Zimmermann
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 64 +
Now that we have the infrastructure in place, we can raise the maximum
pixel rate we can reach for HDMI0 on the BCM2711.
HDMI1 is left untouched since its pixelvalve has a smaller FIFO and
would need a clock faster than what we can provide to support the same
modes.
Acked-by: Thomas Zimmermann
The BVB clock rate computation doesn't take into account a mode clock of
594MHz that we're going to need to support 4k60.
Acked-by: Thomas Zimmermann
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 17 +
1 file changed, 9
In order to reach the frequencies needed to output at 594MHz, the
firmware needs to be configured with the appropriate parameters in the
config.txt file (enable_hdmi_4kp60 and force_turbo).
Let's detect it at bind time, warn the user if we can't, and filter out
the relevant modes.
Acked-by:
Due to a FIFO that cannot be flushed between the pixelvalve and the HDMI
controllers on BCM2711, we need to carefully disable both at boot time
if they were left enabled by the firmware.
However, at the time we're running that code, the struct drm_connector
encoder pointer isn't set yet, and thus
We'll need to have the HVS binding before the HDMI controllers so that
we can check whether the firmware allows to run in 4kp60. Reorder a bit
the component list, and document the current constraints we're aware of.
Acked-by: Dave Stevenson
Acked-by: Thomas Zimmermann
Signed-off-by: Maxime
The current code does a binary OR on the possible_crtcs variable of the
TXP encoder, while we want to set it to that value instead.
Cc: # v5.9+
Fixes: 39fcb2808376 ("drm/vc4: txp: Turn the TXP into a CRTC of its own")
Acked-by: Thomas Zimmermann
Signed-off-by: Maxime Ripard
---
Since we fixed the hooks to disable the encoder at boot, we now have an
unbalanced clk_disable call at boot since we never enabled them in the
first place.
Let's mimic the state of the hardware and enable the clocks at boot if
the controller is enabled to get the use-count right.
Cc: # v5.10+
Hi,
Here is a series that enables the higher resolutions on the HDMI0 Controller
found in the BCM2711 (RPi4).
In order to work it needs a few adjustments to config.txt, most notably to
enable the enable_hdmi_4kp60 option.
The firmware also has a glitch at the moment and will not properly
On Tue, Apr 13, 2021 at 04:11:29PM +0200, Daniel Vetter wrote:
> On Tue, Apr 13, 2021 at 02:56:02PM +0300, Pekka Paalanen wrote:
> > On Tue, 13 Apr 2021 11:49:03 +0200
> > Daniel Vetter wrote:
> >
> > > It's very confusing for userspace to have to deal with inconsistencies
> > > here, and some
On Tue, Apr 13, 2021 at 01:54:00PM +0200, Lucas Stach wrote:
> Am Dienstag, dem 13.04.2021 um 11:49 +0200 schrieb Daniel Vetter:
> > It's very confusing for userspace to have to deal with inconsistencies
> > here, and some drivers screwed this up a bit. Most just ommitted the
> > format list when
Am Dienstag, dem 13.04.2021 um 16:04 +0200 schrieb Daniel Vetter:
> On Tue, Apr 13, 2021 at 01:47:28PM +0200, Lucas Stach wrote:
> > Am Dienstag, dem 13.04.2021 um 11:48 +0200 schrieb Daniel Vetter:
> > > Since
> > >
> > > commit 890880ddfdbe256083170866e49c87618b706ac7
> > > Author: Paul
On Tue, Apr 13, 2021 at 02:56:02PM +0300, Pekka Paalanen wrote:
> On Tue, 13 Apr 2021 11:49:03 +0200
> Daniel Vetter wrote:
>
> > It's very confusing for userspace to have to deal with inconsistencies
> > here, and some drivers screwed this up a bit. Most just ommitted the
> > format list when
On Tue, Apr 13, 2021 at 01:47:28PM +0200, Lucas Stach wrote:
> Am Dienstag, dem 13.04.2021 um 11:48 +0200 schrieb Daniel Vetter:
> > Since
> >
> > commit 890880ddfdbe256083170866e49c87618b706ac7
> > Author: Paul Kocialkowski
> > Date: Fri Jan 4 09:56:10 2019 +0100
> >
> > drm: Auto-set
No functional changes, just removing the leftovers from the redesign.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_range_manager.c | 35 -
1 file changed, 17 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_range_manager.c
When we want to decouble resource management from buffer management we need to
be able to handle resources separately.
Add a resource pointer and rename bo->mem so that all code needs to
change to access the pointer instead.
No functional change.
Signed-off-by: Christian König
---
Drop some ussage of mem in the code.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index
Change a couple of cases where it makes more sense to use the base size
instead of the number of pages in the resource.
Signed-off-by: Christian König
---
drivers/gpu/drm/nouveau/nouveau_bo.c| 9 -
drivers/gpu/drm/nouveau/nouveau_fbcon.c | 4 ++--
Add a separate manager for the system domain and make function tables
mandatory.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/Makefile | 2 +-
drivers/gpu/drm/ttm/ttm_device.c | 17 +-
drivers/gpu/drm/ttm/ttm_module.h | 3 ++
The alignment is a constant property and shouldn't change.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 2 +-
Init all fields in ttm_resource_alloc() when we create a new resource.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 2 --
drivers/gpu/drm/ttm/ttm_bo.c| 26 -
drivers/gpu/drm/ttm/ttm_bo_util.c | 4 ++--
Hi Yongqiang,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on robh/for-next]
[also build test WARNING on pza/reset/next linus/master v5.12-rc7]
[cannot apply to next-20210413]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when
From: Dave Stevenson
Now that we can export deeper colour depths, add in the signalling
for HDR metadata.
Signed-off-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
Changes from v1:
- Rebased on latest drm-misc-next tag
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 53
Our driver while supporting HDR didn't send the proper colorimetry info
in the AVI infoframe.
Let's add the property needed so that the userspace can let us know what
the colorspace is supposed to be.
Signed-off-by: Maxime Ripard
---
Changes from v1:
- New patch
---
All the drivers that implement HDR output call pretty much the same
function to initialise the hdr_output_metadata property, and while the
creation of that property is in a helper, every driver uses the same
code to attach it.
Provide a helper for it as well
Reviewed-by: Harry Wentland
The intel driver uses the same logic to attach the Colorspace property
in multiple places and we'll need it in vc4 too. Let's move that common
code in a helper.
Signed-off-by: Maxime Ripard
---
Changes from v1:
- New patch
---
drivers/gpu/drm/drm_connector.c | 20
All the drivers that support the HDR metadata property have a similar
function to compare the metadata from one connector state to the next,
and force a mode change if they differ.
All these functions run pretty much the same code, so let's turn it into
an helper that can be shared across those
On Tue, 13 Apr 2021 11:49:03 +0200
Daniel Vetter wrote:
> It's very confusing for userspace to have to deal with inconsistencies
> here, and some drivers screwed this up a bit. Most just ommitted the
> format list when they meant to say that only linear modifier is
> allowed, but some also meant
Am Dienstag, dem 13.04.2021 um 11:49 +0200 schrieb Daniel Vetter:
> It's very confusing for userspace to have to deal with inconsistencies
> here, and some drivers screwed this up a bit. Most just ommitted the
> format list when they meant to say that only linear modifier is
> allowed, but some
Am Dienstag, dem 13.04.2021 um 11:48 +0200 schrieb Daniel Vetter:
> Since
>
> commit 890880ddfdbe256083170866e49c87618b706ac7
> Author: Paul Kocialkowski
> Date: Fri Jan 4 09:56:10 2019 +0100
>
> drm: Auto-set allow_fb_modifiers when given modifiers at plane init
>
> this is done
Add an entry for the new uAPI needed for DG1.
v2(Daniel):
- include the overall upstreaming plan
- add a note for mmap, there are differences here for TTM vs i915
- bunch of other suggestions from Daniel
Signed-off-by: Matthew Auld
Cc: Joonas Lahtinen
Cc: Daniel Vetter
Cc: Dave Airlie
On Tue, Apr 13, 2021 at 11:49:01AM +0200, Daniel Vetter wrote:
> Since
>
> commit 890880ddfdbe256083170866e49c87618b706ac7
> Author: Paul Kocialkowski
> Date: Fri Jan 4 09:56:10 2019 +0100
>
> drm: Auto-set allow_fb_modifiers when given modifiers at plane init
>
> this is done
Hi
Am 13.04.21 um 11:49 schrieb Daniel Vetter:
shmem helpers seem a bit sloppy here by automatically rounding up when
actually creating the buffer, which results in under-reporting of what
we actually have. Caught by igt/vgem_basic tests.
Signed-off-by: Daniel Vetter
Drivers get it more
On Tue, Apr 13, 2021 at 11:29 AM Matthew Auld
wrote:
>
> On Mon, 12 Apr 2021 at 18:01, Daniel Vetter wrote:
> >
> > On Mon, Apr 12, 2021 at 6:08 PM Matthew Auld
> > wrote:
> > >
> > > On Mon, 12 Apr 2021 at 16:17, Daniel Vetter wrote:
> > > >
> > > > On Mon, Apr 12, 2021 at 10:05:25AM +0100,
Hi,
This is a follow-up of the discussion here:
https://lore.kernel.org/linux-clk/20210319150355.xzw7ikwdaga2dwhv@gilmour/
This implements a mechanism to raise and lower clock rates based on consumer
workloads, with an example of such an implementation for the RaspberryPi4 HDMI
controller.
It's not unusual to find clocks being shared across multiple devices
that need to change the rate depending on what the device is doing at a
given time.
The SoC found on the RaspberryPi4 (BCM2711) is in such a situation
between its two HDMI controllers that share a clock that needs to be
raised
The new clock request API allows us to increase the rate of the HSM
clock to match our pixel rate requirements while decreasing it when
we're done, resulting in a better power-efficiency.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 19 ---
Hi, Zack,
On 4/10/21 8:59 PM, Zack Rusin wrote:
Quite often it's a little hard to tell if reservations are already held
in code paths that unpin bo's. While our pinning/unpinning code should
be more explicit that requires a substential amount of work so instead
we can avoid the issues by making
Aside from deleting lots of code the real motivation here is to switch
the mmap over to VM_PFNMAP, to be more consistent with what real gpu
drivers do. They're all VM_PFNMP, which means get_user_pages doesn't
work, and even if you try and there's a struct page behind that,
touching it and mucking
tldr; DMA buffers aren't normal memory, expecting that you can use
them like that (like calling get_user_pages works, or that they're
accounting like any other normal memory) cannot be guaranteed.
Since some userspace only runs on integrated devices, where all
buffers are actually all resident
It's very confusing for userspace to have to deal with inconsistencies
here, and some drivers screwed this up a bit. Most just ommitted the
format list when they meant to say that only linear modifier is
allowed, but some also meant that only implied modifiers are
acceptable (because actually none
Since
commit 890880ddfdbe256083170866e49c87618b706ac7
Author: Paul Kocialkowski
Date: Fri Jan 4 09:56:10 2019 +0100
drm: Auto-set allow_fb_modifiers when given modifiers at plane init
this is done automatically as part of plane init, if drivers set the
modifier list correctly. Which is
Since
commit 890880ddfdbe256083170866e49c87618b706ac7
Author: Paul Kocialkowski
Date: Fri Jan 4 09:56:10 2019 +0100
drm: Auto-set allow_fb_modifiers when given modifiers at plane init
this is done automatically as part of plane init, if drivers set the
modifier list correctly. Which is
Setting the cap without the modifier list is very confusing to
userspace. Fix that by listing the ones we support explicitly.
Stable backport so that userspace can rely on this working in a
reasonable way, i.e. that the cap set implies IN_FORMATS is available.
Cc: sta...@vger.kernel.org
Cc:
Since
commit 890880ddfdbe256083170866e49c87618b706ac7
Author: Paul Kocialkowski
Date: Fri Jan 4 09:56:10 2019 +0100
drm: Auto-set allow_fb_modifiers when given modifiers at plane init
this is done automatically as part of plane init, if drivers set the
modifier list correctly. Which is
Since
commit 890880ddfdbe256083170866e49c87618b706ac7
Author: Paul Kocialkowski
Date: Fri Jan 4 09:56:10 2019 +0100
drm: Auto-set allow_fb_modifiers when given modifiers at plane init
this is done automatically as part of plane init, if drivers set the
modifier list correctly. Which is
Since
commit 890880ddfdbe256083170866e49c87618b706ac7
Author: Paul Kocialkowski
Date: Fri Jan 4 09:56:10 2019 +0100
drm: Auto-set allow_fb_modifiers when given modifiers at plane init
this is done automatically as part of plane init, if drivers set the
modifier list correctly. Which is
shmem helpers seem a bit sloppy here by automatically rounding up when
actually creating the buffer, which results in under-reporting of what
we actually have. Caught by igt/vgem_basic tests.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_gem_shmem_helper.c | 4 ++--
1 file changed, 2
Since
commit 890880ddfdbe256083170866e49c87618b706ac7
Author: Paul Kocialkowski
Date: Fri Jan 4 09:56:10 2019 +0100
drm: Auto-set allow_fb_modifiers when given modifiers at plane init
this is done automatically as part of plane init, if drivers set the
modifier list correctly. Which is
Since
commit 890880ddfdbe256083170866e49c87618b706ac7
Author: Paul Kocialkowski
Date: Fri Jan 4 09:56:10 2019 +0100
drm: Auto-set allow_fb_modifiers when given modifiers at plane init
this is done automatically as part of plane init, if drivers set the
modifier list correctly. Which is
Since
commit 890880ddfdbe256083170866e49c87618b706ac7
Author: Paul Kocialkowski
Date: Fri Jan 4 09:56:10 2019 +0100
drm: Auto-set allow_fb_modifiers when given modifiers at plane init
this is done automatically as part of plane init, if drivers set the
modifier list correctly. Which is
Even when all we support is linear, make that explicit. Otherwise the
uapi is rather confusing.
Cc: sta...@vger.kernel.org
Cc: Pekka Paalanen
Cc: Liviu Dudau
Cc: Brian Starkey
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/arm/malidp_planes.c | 9 +++--
1 file changed, 7 insertions(+),
Since
commit 890880ddfdbe256083170866e49c87618b706ac7
Author: Paul Kocialkowski
Date: Fri Jan 4 09:56:10 2019 +0100
drm: Auto-set allow_fb_modifiers when given modifiers at plane init
this is done automatically as part of plane init, if drivers set the
modifier list correctly. Which is
On Mon, 12 Apr 2021 at 18:01, Daniel Vetter wrote:
>
> On Mon, Apr 12, 2021 at 6:08 PM Matthew Auld
> wrote:
> >
> > On Mon, 12 Apr 2021 at 16:17, Daniel Vetter wrote:
> > >
> > > On Mon, Apr 12, 2021 at 10:05:25AM +0100, Matthew Auld wrote:
> > > > We need to general our accessor for the page
I met below error during boot with i915 builtin if pass
"i915.mitigations=off":
[0.015589] Booting kernel: `off' invalid for parameter `i915.mitigations'
The reason is slab subsystem isn't ready at that time, so kstrdup()
returns NULL. Fix this issue by using stack var instead of kstrdup().
Merged series.
https://cgit.freedesktop.org/drm/drm-misc/commit/?id=6a3608eae6d33a478a29348eb5e9ca330a528ae6
On Sat, 10 Apr 2021 at 20:14, Parshuram Thombare wrote:
>
> This patch series enables HDCP in Cadence MHDP DPI/DP bridge driver.
>
> Changes since v1:
> - Move sapb reg block right after
The value of ret set but will rewriten, so just delete.
Signed-off-by: Tian Tao
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
index
Am 13.04.21 um 09:50 schrieb Thomas Hellström:
Hi!
During the dma_resv conversion of the i915 driver, we've been using ww
transaction lock lists to keep track of ww_mutexes that are locked
during the transaction so that they can be batch unlocked at suitable
locations. Including also the
Add support to overlay plane, in addition to primary and cursor
planes. In this approach, the plane composition still requires an
active primary plane and planes are composed associatively in the
order: (primary <- overlay) <- cursor
It enables to run the following IGT tests successfully:
-
Add support for composing XRGB888 planes in addition to the
ARGB format. In the case of an XRGB plane at the top, the
composition consists of just copying the RGB values of a
pixel from src to dst, without the need for alpha blending
operations for each pixel.
Signed-off-by: Melissa Wen
---
Generalize variables and function names used for planes composition
(from cursor to plane), since we will reuse the operations for both
cursor and overlay types.
No functional change.
Signed-off-by: Melissa Wen
---
drivers/gpu/drm/vkms/vkms_composer.c | 28 ++--
1 file
By using drmm_universal_plane_alloc instead of
drm_universal_plane_init, we let the DRM infrastructure handles
resource allocation and cleanup. We can also get rid of some
code repetitions for plane cleanup, improving code maintainability
in vkms.
Signed-off-by: Melissa Wen
---
Hi!
During the dma_resv conversion of the i915 driver, we've been using ww
transaction lock lists to keep track of ww_mutexes that are locked
during the transaction so that they can be batch unlocked at suitable
locations. Including also the LMEM/VRAM eviction we've ended up with
two static lists
Adding support to overlay type in addition to primary and cursor plane.
The planes composition relies on the z order of the active planes and
only occurs if there is a primary plane (as in the current behavior).
The first patch switches the function of initializing planes from
patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Melissa-Wen/drm-vkms-add-overlay-plane-support/20210413-065337
base:5df924d19629975d565da37eb7268c7bf4d491fe
config: csky-randconfig-r025-20210413
Fix the following clang warning:
drivers/gpu/drm/i915/gvt/gtt.c:590:20: warning: unused function
'ppgtt_set_guest_root_entry' [-Wunused-function].
Reported-by: Abaci Robot
Signed-off-by: Jiapeng Chong
---
drivers/gpu/drm/i915/gvt/gtt.c | 6 --
1 file changed, 6 deletions(-)
diff --git
98 matches
Mail list logo
