Hi
Am 21.05.21 um 21:37 schrieb Javier Martinez Canillas:
The register_gop_device() function registers an "efi-framebuffer" platform
device to match against the efifb driver, to have an early framebuffer for
EFI platforms.
But the Generic System Framebuffers (sysfb) already has support for this
From: Xuezhi Zhang
Fix the following coccicheck warnings:
drivers/gpu/drm//panel/panel-dsi-cm.c:271:8-16:
WARNING: use scnprintf or sprintf
drivers/gpu/drm//panel/panel-dsi-cm.c:251:8-16:
WARNING: use scnprintf or sprintf
Signed-off-by: Xuezhi Zhang
---
drivers/gpu/drm/panel/panel-dsi-cm.c | 4
On Tue, May 11, 2021 at 11:14 AM Zhen Lei wrote:
> When devm_ioremap_resource() fails, a clear enough error message will be
> printed by its subfunction __devm_ioremap_resource(). The error
> information contains the device name, failure cause, and possibly resource
> information.
>
> Therefore,
On Wed, May 19, 2021 at 10:35 PM Corentin Labbe wrote:
> dtb_check complains about #address-cells and #size-cells, so lets
> remove them.
>
> Signed-off-by: Corentin Labbe
Patch applied to the Gemini tree.
Yours,
Linus Walleij
On Wed, May 19, 2021 at 10:35 PM Corentin Labbe wrote:
> The address and reg adds no value to the port node, remove them.
>
> Signed-off-by: Corentin Labbe
Patch applied to the Gemini tree.
Yours,
Linus Walleij
On Wed, May 19, 2021 at 10:35 PM Corentin Labbe wrote:
> Converts display/faraday,tve200.txt to yaml.
>
> Signed-off-by: Corentin Labbe
Patch applied to the DRM misc tree.
Yours,
Linus Walleij
On 2021-05-21 14:57, Stephen Boyd wrote:
Quoting Stephen Boyd (2021-05-07 14:25:02)
Here's a few patches that simplify the aux handling code and bubble up
timeouts and nacks to the upper DRM layers. The goal is to get DRM to
know that the other side isn't there or that there's been a timeout,
in
Hi, Daniel:
Daniel Vetter 於 2021年5月21日 週五 下午5:10寫道：
>
> No need to set it explicitly.
>
> Signed-off-by: Daniel Vetter
> Cc: Laurentiu Palcu
> Cc: Lucas Stach
> Cc: Shawn Guo
> Cc: Sascha Hauer
> Cc: Pengutronix Kernel Team
> Cc: Fabio Estevam
> Cc: NXP Linux Team
> Cc: Philipp Zabel
> C
For patches 5, and 6:
Reviewed-by: Lyude Paul
This week got really busy so I wasn't able to look at the rest of them, but next
week is going to be a lot less busy so I should be able to look at them then
On Mon, 2021-05-17 at 13:08 -0700, Douglas Anderson wrote:
> The primary goal of this serie
Quoting Lee Jones (2021-05-20 05:02:37)
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/msm/dp/dp_catalog.c:206: warning: Function parameter or
> member 'dp_catalog' not described in 'dp_catalog_aux_reset'
> drivers/gpu/drm/msm/dp/dp_catalog.c:206: warning: Excess function
Quoting Doug Anderson (2021-05-21 15:35:33)
> Hi,
>
> On Fri, May 21, 2021 at 3:02 PM Stephen Boyd wrote:
> >
> > Quoting Douglas Anderson (2021-05-21 13:45:50)
> > > Let's use the newly-added nvmem_cell_read_variable_le_u32() to future
> > > proof ourselves a little bit.
> > >
> > > Signed-off-by
Hi,
On Fri, May 21, 2021 at 3:02 PM Stephen Boyd wrote:
>
> Quoting Douglas Anderson (2021-05-21 13:45:50)
> > Let's use the newly-added nvmem_cell_read_variable_le_u32() to future
> > proof ourselves a little bit.
> >
> > Signed-off-by: Douglas Anderson
> > ---
> > The patch that this depends o
Am 2021-05-21 um 11:02 a.m. schrieb Guenter Roeck:
> The first parameter passed to container_of() is the pointer to the work
> structure passed to the worker and never NULL. The NULL check on the
> result of container_of() is therefore unnecessary and misleading.
> Remove it.
>
> This change was ma
Quoting Douglas Anderson (2021-05-21 13:45:50)
> Let's use the newly-added nvmem_cell_read_variable_le_u32() to future
> proof ourselves a little bit.
>
> Signed-off-by: Douglas Anderson
> ---
> The patch that this depends on is now in mainline so it can be merged
> at will. I'm just sending this
Quoting Stephen Boyd (2021-05-07 14:25:02)
> Here's a few patches that simplify the aux handling code and bubble up
> timeouts and nacks to the upper DRM layers. The goal is to get DRM to
> know that the other side isn't there or that there's been a timeout,
> instead of saying that everything is f
IGT: https://patchwork.freedesktop.org/series/90433/
Mesa (Vulkan WSI):
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4037
Ideally, it'd be nice to see a RADV MR and maybe even radeonsi before
we really land on it. However, I think it's proved out well enough in
ANV to at least land t
On Fri 21 May 15:51 CDT 2021, Stephen Boyd wrote:
> Quoting Bjorn Andersson (2021-05-21 09:00:29)
> > On Fri 21 May 05:27 CDT 2021, Krishna Manikandan wrote:
> > > diff --git
> > > a/Documentation/devicetree/bindings/display/msm/dpu-sc7180.yaml
> > > b/Documentation/devicetree/bindings/display/m
Applied. Thanks!
Alex
On Fri, May 21, 2021 at 11:02 AM Guenter Roeck wrote:
>
> The first parameter passed to container_of() is the pointer to the work
> structure passed to the worker and never NULL. The NULL check on the
> result of container_of() is therefore unnecessary and misleading.
> Re
Applied. Thanks!
Alex
On Fri, May 21, 2021 at 9:35 AM Christian König
wrote:
>
> Am 21.05.21 um 11:50 schrieb Jiapeng Chong:
> > Eliminate the follow smatch warning:
> >
> > drivers/gpu/drm/amd/amdgpu/sdma_v5_0.c:449
> > sdma_v5_0_ring_emit_mem_sync() warn: inconsistent indenting.
> >
> > Repor
On Fri, May 21, 2021 at 4:41 PM Andrey Grodzovsky
wrote:
>
> Problem:
> When device goes into sleep state due to prolonged
s/sleep state/runtime suspend/
> innactivity (e.g. BACO sleep) and then hot unplugged,
inactivity
> PCI core will try to wake up the device as part of
> unplug process. Si
Quoting Bjorn Andersson (2021-05-21 09:00:29)
> On Fri 21 May 05:27 CDT 2021, Krishna Manikandan wrote:
> > diff --git a/Documentation/devicetree/bindings/display/msm/dpu-sc7180.yaml
> > b/Documentation/devicetree/bindings/display/msm/dpu-sc7180.yaml
> [..]
> > + ports:
> > +$ref: /sc
Quoting Krishna Manikandan (2021-05-21 03:27:23)
> Add YAML schema for the device tree bindings for DSI PHY.
>
> Signed-off-by: Krishna Manikandan
>
> Changes in v1:
>- Merge dsi-phy.yaml and dsi-phy-10nm.yaml (Stephen Boyd)
>- Remove qcom,dsi-phy-regulator-ldo-mode (Stephen Boyd)
>- A
Quoting Krishna Manikandan (2021-05-21 03:27:22)
> Add YAML schema for the device tree bindings for DSI
>
> Signed-off-by: Krishna Manikandan
>
> Changes in v1:
> - Separate dsi controller bindings to a separate patch (Stephen Boyd)
> - Merge dsi-common-controller.yaml and dsi-controller-m
Quoting Krishna Manikandan (2021-05-21 03:27:21)
> MSM Mobile Display Subsystem (MDSS) encapsulates sub-blocks
> like DPU display controller, DSI etc. Add YAML schema
> for DPU device tree bindings.
>
> Signed-off-by: Krishna Manikandan
>
> Changes in v2:
> - Changed dpu to DPU (Sam Ravnborg)
Quoting Krishna Manikandan (2021-05-21 03:27:24)
> Add bindings for Snapdragon DisplayPort controller driver.
>
> Signed-off-by: Chandan Uddaraju
> Signed-off-by: Vara Reddy
> Signed-off-by: Tanmay Shah
> Signed-off-by: Kuogee Hsieh
> Signed-off-by: Krishna Manikandan
>
> Changes in V2:
> -Pro
Let's use the newly-added nvmem_cell_read_variable_le_u32() to future
proof ourselves a little bit.
Signed-off-by: Douglas Anderson
---
The patch that this depends on is now in mainline so it can be merged
at will. I'm just sending this as a singleton patch to make it obvious
that there are no de
Problem:
When device goes into sleep state due to prolonged
innactivity (e.g. BACO sleep) and then hot unplugged,
PCI core will try to wake up the device as part of
unplug process. Since the device is gone all HW
programming during rpm resume fails leading
to a bad SW state later during pci remove
Make it's name not feature but function descriptive.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 6 +++---
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c| 4 ++--
drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 2
Will do.
Andrey
On 2021-05-21 4:18 p.m., Alex Deucher wrote:
On Fri, May 21, 2021 at 4:14 PM Andrey Grodzovsky
wrote:
Problem:
When device goes into sleep state due to prolonged
innactivity (e.g. BACO sleep) and then hot unplugged,
PCI core will try to wake up the device as part of
unplug pro
On Fri, May 21, 2021 at 4:14 PM Andrey Grodzovsky
wrote:
>
> Problem:
> When device goes into sleep state due to prolonged
> innactivity (e.g. BACO sleep) and then hot unplugged,
> PCI core will try to wake up the device as part of
> unplug process. Since the device is gone all HW
> programming du
Problem:
When device goes into sleep state due to prolonged
innactivity (e.g. BACO sleep) and then hot unplugged,
PCI core will try to wake up the device as part of
unplug process. Since the device is gone all HW
programming during rpm resume fails leading
to a bad SW state later during pci remove
On Fri, May 21, 2021 at 2:40 AM Lee Jones wrote:
> On Tue, 10 Nov 2020 at 03:49, John Stultz wrote:
>> This series reworks the system heap to use sgtables, and then
>> consolidates the pagelist method from the heap-helpers into the
>> CMA heap. After which the heap-helpers logic is removed (as it
On Fri, May 14, 2021 at 02:14:55PM -0400, Lyude Paul wrote:
> 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 c
On Fri, May 14, 2021 at 02:15:02PM -0400, Lyude Paul wrote:
> 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 t
The register_gop_device() function registers an "efi-framebuffer" platform
device to match against the efifb driver, to have an early framebuffer for
EFI platforms.
But the Generic System Framebuffers (sysfb) already has support for this.
Instead of having duplicated logic for x86 and other archi
The x86 architecture platform has a Generic System Framebuffers (sysfb)
support, that register a system frambuffer platform devices. It either
registers a "simple-framebuffer" for the simple{fb,drm} drivers or legacy
VGA/EFI FB devices for the vgafb/efifb drivers.
Besides this, the EFI initializat
The x86 architecture has generic support to register a system framebuffer
platform device. It either registers a "simple-framebuffer" if the config
option CONFIG_X86_SYSFB is enabled, or a legacy VGA/VBE/EFI FB device.
But the code is generic enough to be reused by other architectures and can
be m
Hi
Am 21.05.21 um 19:18 schrieb Javier Martinez Canillas:
On 5/21/21 6:53 PM, Thomas Zimmermann wrote:
[snip]
So what with all the drivers which do _not_ have drm in their name? Also
I'm never sure how much these are uapi or not ...
That someone could threat as an uapi is a fair point in
On Wed, May 19, 2021 at 04:21:23PM +0800, Zhenyu Wang wrote:
> On 2021.05.19 10:31:18 +0200, Greg Kroah-Hartman wrote:
> > On Wed, May 19, 2021 at 04:03:13PM +0800, Zhenyu Wang wrote:
> > > On 2021.05.18 18:28:53 +0200, Greg Kroah-Hartman wrote:
> > > > On Tue, May 18, 2021 at 06:17:05PM +0200, Gre
On Fri, 21 May 2021 15:57:24 +0530, Krishna Manikandan wrote:
> Add bindings for Snapdragon DisplayPort controller driver.
>
> Signed-off-by: Chandan Uddaraju
> Signed-off-by: Vara Reddy
> Signed-off-by: Tanmay Shah
> Signed-off-by: Kuogee Hsieh
> Signed-off-by: Krishna Manikandan
>
> Change
On Fri, May 21, 2021 at 03:57:22PM +0530, Krishna Manikandan wrote:
> Add YAML schema for the device tree bindings for DSI
>
> Signed-off-by: Krishna Manikandan
>
> Changes in v1:
> - Separate dsi controller bindings to a separate patch (Stephen Boyd)
> - Merge dsi-common-controller.yaml
On Fri, May 21, 2021 at 8:08 PM Christian König
wrote:
>
> Am 21.05.21 um 17:16 schrieb Daniel Vetter:
> > On Fri, May 21, 2021 at 05:00:46PM +0200, Bas Nieuwenhuizen wrote:
> >> On Fri, May 21, 2021 at 4:37 PM Daniel Vetter wrote:
> >>> On Fri, May 21, 2021 at 11:46:23AM +0200, Bas Nieuwenhuizen
On Fri, 21 May 2021 15:57:23 +0530, Krishna Manikandan wrote:
> Add YAML schema for the device tree bindings for DSI PHY.
>
> Signed-off-by: Krishna Manikandan
>
> Changes in v1:
>- Merge dsi-phy.yaml and dsi-phy-10nm.yaml (Stephen Boyd)
>- Remove qcom,dsi-phy-regulator-ldo-mode (Stephen
On Fri, 21 May 2021 15:57:21 +0530, Krishna Manikandan wrote:
> MSM Mobile Display Subsystem (MDSS) encapsulates sub-blocks
> like DPU display controller, DSI etc. Add YAML schema
> for DPU device tree bindings.
>
> Signed-off-by: Krishna Manikandan
>
> Changes in v2:
> - Changed dpu to DPU
Hi, Christian.
I was just going over some old patches and I was just looking at your series
introducing use_tt:
https://patchwork.freedesktop.org/series/80078/ and the change
https://patchwork.freedesktop.org/patch/382079/?series=80078&rev=1
Do you happen to remember what was the worry behind
From: Chris Wilson
Now that we no longer switch back and forth between guc and execlists,
we no longer need to restore the backend's vfunc and can leave them set
after initialisation. The only catch is that we lose the submission on
wedging and still need to reset the submit_request vfunc on unwe
From: Chris Wilson
Since we setup the submission method for the engines once, it is easy to
assign an enum and use that instead of probing into the backends.
Signed-off-by: Matthew Brost
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Reviewed-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/in
As discussed in [1] start merging some support patches as a precursor to
GuC submission the i915. This is step #1 mentioned in [1].
[1] https://patchwork.freedesktop.org/series/89844/
Signed-off-by: Matthew Brost
Chris Wilson (3):
drm/i915/gt: Move engine setup out of set_default_submission
From: Chris Wilson
The different submission backends each have their own preferred
behaviour and interrupt setup. Let each handle their own interrupts.
This becomes more useful later as we to extract the use of auxiliary
state in the interrupt handler that is backend specific.
Signed-off-by: Ma
Am 21.05.21 um 18:27 schrieb Jason Ekstrand:
On Fri, May 21, 2021 at 2:51 AM Christian König
wrote:
Am 20.05.21 um 21:00 schrieb Jason Ekstrand:
From: Christian König
Add a helper to iterate over all fences in a dma_fence_array object.
v2 (Jason Ekstrand)
- Return NULL from dma_fence_arr
Am 21.05.21 um 17:16 schrieb Daniel Vetter:
On Fri, May 21, 2021 at 05:00:46PM +0200, Bas Nieuwenhuizen wrote:
On Fri, May 21, 2021 at 4:37 PM Daniel Vetter wrote:
On Fri, May 21, 2021 at 11:46:23AM +0200, Bas Nieuwenhuizen wrote:
On Fri, May 21, 2021 at 11:10 AM Daniel Vetter wrote:
---
On Fri, 7 May 2021 at 16:05, Maxime Ripard wrote:
>
> 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 con
Hi Maxime
On Fri, 7 May 2021 at 16:05, Maxime Ripard wrote:
>
> At boot, we can't rely on the vc4_get_crtc_encoder since we don't have a
> state yet and thus will not be able to figure out which connector is
> attached to our CRTC.
>
> However, we have a muxing bit in the CRTC register we can use
Hi Maxime
On Fri, 7 May 2021 at 16:05, Maxime Ripard wrote:
>
> The vc4_get_crtc_encoder function currently only works when the
> connector->state->crtc pointer is set, which is only true when the
> connector is currently enabled.
>
> However, we use it as part of the disable path as well, and ou
On Thu, May 20, 2021 at 02:00:05PM -0500, Jason Ekstrand wrote:
> Add a helper function to get a single fence representing
> all fences in a dma_resv object.
>
> This fence is either the only one in the object or all not
> signaled fences of the object in a flatted out dma_fence_array.
>
> v2 (Ja
Hi Maxime
Thanks for the patch.
On Fri, 7 May 2021 at 16:06, Maxime Ripard wrote:
>
> It looks like some displays (like the LG 27UL850-W) don't enable the
> scrambling when the HDMI driver enables it. However, if we set later the
> scrambler enable bit, the display will work as expected.
>
> Let
Hi Maxime
On Fri, 7 May 2021 at 16:06, Maxime Ripard wrote:
>
> 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
Reviewed-by: Dave Stevens
Hi Maxime
Thanks for the patch
On Fri, 7 May 2021 at 16:05, Maxime Ripard wrote:
>
> The vc4_crtc_config_pv will need to access the drm_atomic_state
> structure and its only parent function, vc4_crtc_atomic_enable already
> has access to it. Let's pass it as a parameter.
>
> Fixes: 792c3132bc1b
On Fri 21 May 05:27 CDT 2021, Krishna Manikandan wrote:
> Add bindings for Snapdragon DisplayPort controller driver.
>
Reviewed-by: Bjorn Andersson
Regards,
Bjorn
> Signed-off-by: Chandan Uddaraju
> Signed-off-by: Vara Reddy
> Signed-off-by: Tanmay Shah
> Signed-off-by: Kuogee Hsieh
> Sig
On 5/21/21 6:53 PM, Thomas Zimmermann wrote:
[snip]
>>
>> So what with all the drivers which do _not_ have drm in their name? Also
>> I'm never sure how much these are uapi or not ...
>
That someone could threat as an uapi is a fair point indeed.
> Why do we need a suffix anyway?
>
Yes, I th
On Fri 21 May 05:27 CDT 2021, Krishna Manikandan wrote:
> Add YAML schema for the device tree bindings for DSI PHY.
>
> Signed-off-by: Krishna Manikandan
>
> Changes in v1:
>- Merge dsi-phy.yaml and dsi-phy-10nm.yaml (Stephen Boyd)
>- Remove qcom,dsi-phy-regulator-ldo-mode (Stephen Boyd
On Fri 21 May 05:27 CDT 2021, Krishna Manikandan wrote:
> Add YAML schema for the device tree bindings for DSI
>
Reviewed-by: Bjorn Andersson
Regards,
Bjorn
> Signed-off-by: Krishna Manikandan
>
> Changes in v1:
> - Separate dsi controller bindings to a separate patch (Stephen Boyd)
>
On Fri 21 May 11:00 CDT 2021, Bjorn Andersson wrote:
> On Fri 21 May 05:27 CDT 2021, Krishna Manikandan wrote:
> > diff --git a/Documentation/devicetree/bindings/display/msm/dpu-sc7180.yaml
> > b/Documentation/devicetree/bindings/display/msm/dpu-sc7180.yaml
> [..]
> > + ports:
> > +$
On Fri, May 21, 2021 at 01:00:54PM +0100, Tvrtko Ursulin wrote:
>
> On 19/05/2021 00:58, Matthew Brost wrote:
> > Add entry fpr i915 new parallel submission uAPI plan.
> >
> > v2:
> > (Daniel Vetter):
> >- Expand logical order explaination
> >- Add dummy header
> >- Only allow N BBs
Hi
Am 21.05.21 um 17:33 schrieb Daniel Vetter:
On Fri, May 21, 2021 at 03:19:10PM +0200, Javier Martinez Canillas wrote:
Framebuffer devices that are registered by DRM drivers for fbdev emulation
have a "drmfb" suffix in their name. But makes them to be quite confusing
if a driver already has "
On Thu, May 20, 2021 at 09:41:20PM +0200, Daniel Vetter wrote:
> On Thu, May 20, 2021 at 11:57:44AM +0100, Tvrtko Ursulin wrote:
> >
> > On 20/05/2021 10:54, Daniel Vetter wrote:
> > > On Wed, May 19, 2021 at 7:19 PM Matthew Brost
> > > wrote:
> > > >
> > > > On Wed, May 19, 2021 at 01:10:04PM
On Fri, May 21, 2021 at 2:51 AM Christian König
wrote:
>
> Am 20.05.21 um 21:00 schrieb Jason Ekstrand:
> > From: Christian König
> >
> > Add a helper to iterate over all fences in a dma_fence_array object.
> >
> > v2 (Jason Ekstrand)
> > - Return NULL from dma_fence_array_first if head == NULL
On Thu, May 20, 2021 at 09:44:59PM +0200, Daniel Vetter wrote:
> On Thu, May 20, 2021 at 08:10:59AM -0700, Matthew Brost wrote:
> > On Thu, May 20, 2021 at 11:54:25AM +0200, Daniel Vetter wrote:
> > > On Wed, May 19, 2021 at 7:19 PM Matthew Brost
> > > wrote:
> > > >
> > > > On Wed, May 19, 2021
On Fri, May 21, 2021 at 10:35:37AM +0200, Christian König wrote:
> Am 20.05.21 um 23:38 schrieb Jason Ekstrand:
> > On Thu, May 20, 2021 at 10:46 AM Matthew Brost
> > wrote:
> > > On Thu, May 20, 2021 at 01:11:59PM +0200, Christian König wrote:
> > > > Am 19.05.21 um 18:51 schrieb Matthew Brost:
On Fri 21 May 05:27 CDT 2021, Krishna Manikandan wrote:
> diff --git a/Documentation/devicetree/bindings/display/msm/dpu-sc7180.yaml
> b/Documentation/devicetree/bindings/display/msm/dpu-sc7180.yaml
[..]
> + ports:
> +$ref: /schemas/graph.yaml#/properties/ports
> +description:
On Fri, May 21, 2021 at 03:19:10PM +0200, Javier Martinez Canillas wrote:
> Framebuffer devices that are registered by DRM drivers for fbdev emulation
> have a "drmfb" suffix in their name. But makes them to be quite confusing
> if a driver already has "drm" in its name:
>
> $ cat /proc/fb
> 0 roc
Since objects can be migrated or evicted when not pinned or locked,
update the checks for lmem residency or future residency so that
the value returned is not immediately stale.
Signed-off-by: Thomas Hellström
Reviewed-by: Matthew Auld
---
v2: Simplify i915_gem_object_migratable() (Reported by M
Most logical place to introduce TTM buffer objects is as an i915
gem object backend. We need to add some ops to account for added
functionality like delayed delete and LRU list manipulation.
Initially we support only LMEM and SYSTEM memory, but SYSTEM
(which in this case means evicted LMEM objects
If the bo is idle when calling ttm_bo_pipeline_gutting(), we unnecessarily
create a ghost object and push it out to delayed destroy.
Fix this by adding a path for idle, and document the function.
Also avoid having the bo end up in a bad state vulnerable to user-space
triggered kernel BUGs if the c
The internal ttm_bo_util memcpy uses ioremap functionality, and while it
probably might be possible to use it for copying in- and out of
sglist represented io memory, using io_mem_reserve() / io_mem_free()
callbacks, that would cause problems with fault().
Instead, implement a method mapping page-b
We are calling the eviction_valuable driver callback at eviction time to
determine whether we actually can evict a buffer object.
The upcoming i915 TTM backend needs the same functionality for swapout,
and that might actually be beneficial to other drivers as well.
Add an eviction_valuable call al
Memcpy from wc will be used as well by TTM memcpy.
Move it to core drm, and make the interface do the right thing
even on !X86.
Cc: Christian König
Cc: Daniel Vetter
Cc: Dave Airlie
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/Makefile | 2 +-
drivers/gpu/drm/drm_
Use fast wc memcpy for reading out of wc memory for TTM bo moves.
Cc: Dave Airlie
Cc: Christian König
Cc: Daniel Vetter
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/ttm/ttm_bo_util.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_
Embed a struct ttm_buffer_object into the i915 gem object, making sure
we alias the gem object part. It's a bit unfortunate that the
struct ttm_buffer_ojbect embeds a gem object since we otherwise could
make the TTM part private to the TTM backend, and use the usual
i915 gem object for the other ba
Temporarily remove the buddy allocator and related selftests
and hook up the TTM range manager for i915 regions.
Also modify the mock region selftests somewhat to account for a
fragmenting manager.
Signed-off-by: Thomas Hellström
Reviewed-by: Matthew Auld #v2
---
v2:
- Fix an error unwind in lm
We are currently sharing the VM reservation locks across a number of
gem objects with page-table memory. Since TTM will individiualize the
reservation locks when freeing objects, including accessing the shared
locks, make sure that the shared locks are not freed until that is done.
For PPGTT we add
All users of this function actually want the dma segment sizes, but that's
not what's calculated. Fix that and rename the function to
i915_sg_dma_sizes to reflect what's calculated.
Signed-off-by: Thomas Hellström
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 2 +-
Any sleeping dma_resv lock taken while the vma pages_mutex is held
will cause a lockdep splat.
Move the i915_gem_object_pin_pages() call out of the pages_mutex
critical section.
Signed-off-by: Thomas Hellström
Reviewed-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/i915_vma.c | 29 +
This is an initial patch series to move discrete memory management over to
TTM. It will be followed up shortly with adding more functionality.
The buddy allocator is temporarily removed along with its selftests and
It is replaced with the TTM range manager and some selftests are adjusted
to accoun
On Fri, May 21, 2021 at 09:03:06PM +0800, Zou Wei wrote:
> pm_runtime_get_sync will increment pm usage counter even it failed.
> Forgetting to putting operation will result in reference leak here.
> Fix it by replacing it with pm_runtime_resume_and_get to keep usage
> counter balanced.
>
> Reporte
On Fri, May 21, 2021 at 05:06:06PM +0800, Tian Tao wrote:
> use pm_runtime_resume_and_get() to replace pm_runtime_get_sync and
> pm_runtime_put_noidle.
It would be good to explain why: Apparently get_sync increments the
refcount even if it fails, which ususally leads to leaks.
With that or simila
On Fri, May 21, 2021 at 06:19:30PM +0530, Vinod Koul wrote:
> We required a helper to create and set the dsc_dce_header, so add the
> dsc_dce_header and API drm_dsc_dsi_pps_header_init
>
> Signed-off-by: Vinod Koul
> ---
> drivers/gpu/drm/drm_dsc.c | 11 +++
> include/drm/drm_dsc.h |
On Fri, May 21, 2021 at 10:26:28AM +0200, Christian König wrote:
> Am 21.05.21 um 10:24 schrieb Daniel Vetter:
> > We have this nice kerneldoc, but forgot to include it.
>
> Well I didn't forgot it, I just didn't had time to double check that it is
> bug free :)
It does seem to generate decent lo
On Fri, May 21, 2021 at 05:00:46PM +0200, Bas Nieuwenhuizen wrote:
> On Fri, May 21, 2021 at 4:37 PM Daniel Vetter wrote:
> >
> > On Fri, May 21, 2021 at 11:46:23AM +0200, Bas Nieuwenhuizen wrote:
> > > On Fri, May 21, 2021 at 11:10 AM Daniel Vetter
> > > wrote:
> > > > ---
> > > > drivers/gpu/
On 5/21/21 12:09 PM, Daniel Vetter wrote:
> Goes through all the drivers and deletes the default hook since it's
> the default now.
>
> Signed-off-by: Daniel Vetter
Acked-by: Oleksandr Andrushchenko
On Fri, May 21, 2021 at 11:10:57AM +0200, Daniel Vetter wrote:
> Spotted while trying to convert panfrost to these.
>
> Signed-off-by: Daniel Vetter
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Thomas Zimmermann
> Cc: David Airlie
> Cc: Daniel Vetter
Cc: Emma Anholt
As original autho
The first parameter passed to container_of() is the pointer to the work
structure passed to the worker and never NULL. The NULL check on the
result of container_of() is therefore unnecessary and misleading.
Remove it.
This change was made automatically with the following Coccinelle script.
@@
typ
On Fri, May 21, 2021 at 4:37 PM Daniel Vetter wrote:
>
> On Fri, May 21, 2021 at 11:46:23AM +0200, Bas Nieuwenhuizen wrote:
> > On Fri, May 21, 2021 at 11:10 AM Daniel Vetter
> > wrote:
> > > ---
> > > drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 4 ++--
> > > 1 file changed, 2 insertions(+), 2 del
On Fri, May 21, 2021 at 07:58:57AM -0700, Rob Clark wrote:
> On Fri, May 21, 2021 at 2:10 AM Daniel Vetter wrote:
> >
> > - msm is mildly entertaining. It also supports MSM_SUBMIT_NO_IMPLICIT,
> > but because it doesn't use the drm/scheduler it handles fences from
> > the wrong context with a
On Fri, May 21, 2021 at 2:10 AM Daniel Vetter wrote:
>
> - msm is mildly entertaining. It also supports MSM_SUBMIT_NO_IMPLICIT,
> but because it doesn't use the drm/scheduler it handles fences from
> the wrong context with a synchronous dma_fence_wait. See
> submit_fence_sync() leading to ms
On Fri, May 21, 2021 at 11:32:48AM +0200, Lucas Stach wrote:
> Am Freitag, dem 21.05.2021 um 11:09 +0200 schrieb Daniel Vetter:
> > Scheduler takes care of its own locking, dont worry. For everything else
> > there's reservation locking on each bo.
> >
> > So seems to be entirely redundnant and ju
On Fri 21 May 07:49 CDT 2021, Vinod Koul wrote:
> DSC enables streams to be compressed before we send to panel. This
> requires DSC enabled encoder and a panel to be present. So we add this
> information in board DTS and find if DSC can be enabled and the
> parameters required to configure DSC are
On Fri, May 21, 2021 at 11:46:23AM +0200, Bas Nieuwenhuizen wrote:
> On Fri, May 21, 2021 at 11:10 AM Daniel Vetter wrote:
> >
> > Docs for struct dma_resv are fairly clear:
> >
> > "A reservation object can have attached one exclusive fence (normally
> > associated with write operations) or N sha
Hello Juha-Pekka
We are seeing the CRC failures on Jasperlake systems. Sometimes the test passes
and sometimes it fails throwing CRC error.
Regards
Vidya
-Original Message-
From: Juha-Pekka Heikkila
Sent: Friday, May 21, 2021 5:00 PM
To: Srinivas, Vidya ;
intel-...@lists.freedesktop.
On Fri, May 21, 2021 at 09:43:59AM +0200, Christian König wrote:
> Am 20.05.21 um 19:08 schrieb Daniel Vetter:
> > [SNIP]
> > > AH! So we are basically telling the fence backend that we have just
> > > missed an event we waited for.
> > >
> > > So what we want to know is how long the frontend want
1 - 100 of 185 matches
Mail list logo
