Am 14.04.21 um 08:48 schrieb Felix Kuehling:
Pages in SG BOs were not allocated by TTM. So don't count them against
TTM's pages limit.
Signed-off-by: Felix Kuehling
Reviewed-by: Christian König
Going to pick that one up for inclusion in drm-misc-next.
Regards,
Christian.
---
drivers/gp
Sorry for the spam. I mis-spelled the amd-gfx list on the To: line of
this patch series. Please ignore this and see the patch series I sent a
minute later.
Regards,
Felix
On 2021-04-14 2:46 a.m., Felix Kuehling wrote:
This patch series fixes DMA-mappings of system memory (GTT and userptr)
f
amdgpu_ttm_tt_unpopulate can be called during bo_destroy. The dmabuf->resv
must not be held by the caller or dma_buf_detach will deadlock. This is
probably not the right fix. I get a recursive lock warning with the
reservation held in ttm_bo_release. Should unmap_attachment move to
backend_unbind i
Add BO-type specific helpers functions to DMA-map and unmap
kfd_mem_attachments. Implement this functionality for userptrs by creating
one SG BO per GPU and filling it with a DMA mapping of the pages from the
original mem->bo.
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_a
Use DMABufs with dynamic attachment to DMA-map GTT BOs on other GPUs.
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h| 2 +
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 74 ++-
2 files changed, 75 insertions(+), 1 deletion(-)
diff --git a/dri
Pages in SG BOs were not allocated by TTM. So don't count them against
TTM's pages limit.
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/ttm/ttm_tt.c | 27 ++-
1 file changed, 18 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm
This is needed to avoid deadlocks with DMA buf import in the next patch.
Also move PT/PD validation out of kfd_mem_attach, that way the caller
can bo this unconditionally.
Signed-off-by: Felix Kuehling
---
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 72 +++
1 file changed, 42
DMA map kfd_mem_attachments in update_gpuvm_pte. This function is called
with the BO and page tables reserved, so we can safely update the DMA
mapping.
DMA unmap when a BO is unmapped from a GPU and before updating mappings
in restore workers.
Signed-off-by: Felix Kuehling
---
.../gpu/drm/amd/a
This name is more fitting, especially for the changes coming next to
support multi-GPU systems with proper DMA mappings. Cleaned up the code
and renamed some related functions and variables to improve readability.
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h|
Do AQL queue double-mapping with a single attach call. That will make it
easier to create per-GPU BOs later, to be shared between the two BO VA
mappings on the same GPU.
Freeing the attachments is not necessary if map_to_gpu fails. These will be
cleaned up when the kdg_mem object is destroyed in
a
For now they all reference the same BO. For correct DMA mappings they will
refer to different BOs per-GPU.
Signed-off-by: Felix Kuehling
---
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 22 ++-
1 file changed, 17 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/amd/
This patch series fixes DMA-mappings of system memory (GTT and userptr)
for KFD running on multi-GPU systems with IOMMU enabled. One SG-BO per
GPU is needed to maintain the DMA mappings of each BO.
I ran into some reservation issues when unmapping or freeing DMA-buf
imports. There are a few FIXME
Use DMABufs with dynamic attachment to DMA-map GTT BOs on other GPUs.
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h| 2 +
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 74 ++-
2 files changed, 75 insertions(+), 1 deletion(-)
diff --git a/dri
amdgpu_ttm_tt_unpopulate can be called during bo_destroy. The dmabuf->resv
must not be held by the caller or dma_buf_detach will deadlock. This is
probably not the right fix. I get a recursive lock warning with the
reservation held in ttm_bo_release. Should unmap_attachment move to
backend_unbind i
Pages in SG BOs were not allocated by TTM. So don't count them against
TTM's pages limit.
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/ttm/ttm_tt.c | 27 ++-
1 file changed, 18 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm
This is needed to avoid deadlocks with DMA buf import in the next patch.
Also move PT/PD validation out of kfd_mem_attach, that way the caller
can bo this unconditionally.
Signed-off-by: Felix Kuehling
---
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 72 +++
1 file changed, 42
Add BO-type specific helpers functions to DMA-map and unmap
kfd_mem_attachments. Implement this functionality for userptrs by creating
one SG BO per GPU and filling it with a DMA mapping of the pages from the
original mem->bo.
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_a
DMA map kfd_mem_attachments in update_gpuvm_pte. This function is called
with the BO and page tables reserved, so we can safely update the DMA
mapping.
DMA unmap when a BO is unmapped from a GPU and before updating mappings
in restore workers.
Signed-off-by: Felix Kuehling
---
.../gpu/drm/amd/a
Do AQL queue double-mapping with a single attach call. That will make it
easier to create per-GPU BOs later, to be shared between the two BO VA
mappings on the same GPU.
Freeing the attachments is not necessary if map_to_gpu fails. These will be
cleaned up when the kdg_mem object is destroyed in
a
This patch series fixes DMA-mappings of system memory (GTT and userptr)
for KFD running on multi-GPU systems with IOMMU enabled. One SG-BO per
GPU is needed to maintain the DMA mappings of each BO.
I ran into some reservation issues when unmapping or freeing DMA-buf
imports. There are a few FIXME
For now they all reference the same BO. For correct DMA mappings they will
refer to different BOs per-GPU.
Signed-off-by: Felix Kuehling
---
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 22 ++-
1 file changed, 17 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/amd/
This name is more fitting, especially for the changes coming next to
support multi-GPU systems with proper DMA mappings. Cleaned up the code
and renamed some related functions and variables to improve readability.
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h|
Am 08.04.21 um 01:12 schrieb Felix Kuehling:
DRM allows access automatically when it creates a GEM handle for a BO.
KFD BOs don't have GEM handles, so KFD needs to manage access manually.
Ok, double checking the code that makes sense.
Signed-off-by: Felix Kuehling
Acked-by: Christian König
Hi Ville,
On Tue, 13 Apr 2021 19:59:34 +0300 Ville Syrjälä wrote:
>
>
> 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
> > `i9
Hi Gerd,
Speaking of the modifier, we notice that the virtio-gpu driver's
mode_config.allow_fb_modifiers = false, which means virtio-gpu doesn't support
modifier. With mode_config.allow_fb_modifiers=false, the DRM Modifier API would
fail.
So, do you know if there is any concern about letting
Screen flickers on Innolux panel when clock rate 54 is in use.
According to the panel vendor, though clock rate 54 is advertised,
but the max clock rate it really supports is 27.
So use slow and wide training for panels with DPCP rev < 1.4 to resolve
the issue. User also confirmed the
Don`t simple disable all the HD-irq, should race the region in the
intel_breadcrumbs_disarm_irq() only.
BUG: sleeping function called from invalid context at
kernel/locking/rtmutex.c:969
#0: 89c4c00ca970 ((wq_completion)events){+.+.}-{0:0}, at:
process_one_work+0x1cf/0x6d0
#1: a433c1
Hi,all
This lockdep warning is only in the RT kernel.
Which is introduced by this
path:https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c?h=v5.12-rc7&id=9d5612ca165a58aacc160465532e7998b9aab270
Fix it.
Ju
Hi,
Le 13/04/2021 à 22:56, Paul Cercueil a écrit :
> 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-f
On Tue, 13 Apr 2021 19:59:34 +0300 Ville Syrjälä wrote:
>
> 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
Hi Rob,
Le 13/04/2021 à 22:21, Robert Foss a écrit :
> 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 = i
Fix the following gcc warning:
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c:456:31: warning: variable ‘vcs’ set
but not used [-Wunused-but-set-variable].
Reported-by: Abaci Robot
Signed-off-by: Jiapeng Chong
---
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
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().
F
This code should propagate the error from intel_overlay_pin_fb()
but currently it returns success.
Fixes: 1b321026e213 ("drm/i915: Pass ww ctx to intel_pin_to_display_plane")
Signed-off-by: Dan Carpenter
---
drivers/gpu/drm/i915/display/intel_overlay.c | 4 +++-
1 file changed, 3 insertions(+),
The intel_gvt_init_vgpu_type_groups() function is only called from
intel_gvt_init_device(). If it fails then the intel_gvt_init_device()
prints the error code and propagates it back again. That's a bug
because false is zero/success. The fix is to modify it to return zero
or negative error codes
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 f
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
("drm/nouveau/bl
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 dp_display_disab
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 dongl
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 a/Docume
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 c
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
i
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 t
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 ma
On Sun, Apr 11, 2021 at 05:53:32PM -0700, Rob Clark wrote:
> Hi Dave&Daniel,
>
> 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
>
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 c103b850721e4a79ff9578
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 j
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, 1
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 = it66121_bridge_mode_se
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
> > ---
> > .../bindings/di
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: a6c0fd3d5a8
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")
> BugLin
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 Feng
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 modul
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 kstrdup()
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
https
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
https://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 -
> drivers/gpu/drm/n
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 &DRM_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 insertions
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 w
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 +
drivers/gpu/drm/vc4/vc
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
R
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 insertions
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: Thoma
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 Ripar
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
---
drivers/gpu/drm
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+
Fi
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 release
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 dr
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 t
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 Kocialko
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 th
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 all
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
b/drivers/gpu/
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
---
.../gpu/drm/
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 984dcf5a475
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 ++--
drivers/gpu/drm/nouveau/nouveau_gem.
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 ++
drivers/gpu/drm/ttm/ttm_resourc
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 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_vram_m
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 ++--
drivers/gpu/drm/tt
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
---
drivers/gpu/drm/vc4/vc4_
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
Reviewed-
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 dr
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 als
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 automati
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 automatical
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 wron
1 - 100 of 131 matches
Mail list logo
