Hello Jeff,
On 21-05-21, 08:09, Jeffrey Hugo wrote:
> On Fri, May 21, 2021 at 6:50 AM Vinod Koul wrote:
> >
> > Display Stream Compression (DSC) compresses the display stream in host which
> > is later decoded by panel. This series enables this for Qualcomm msm driver.
> > This was tested on
On 24-05-21, 10:08, Bjorn Andersson wrote:
> On Mon 24 May 02:30 CDT 2021, Vinod Koul wrote:
>
> > On 21-05-21, 09:42, Bjorn Andersson wrote:
> > > On Fri 21 May 07:49 CDT 2021, Vinod Koul wrote:
> > >
> > > > DSC enables streams to be compressed before we send to panel. This
> > > > requires
Hi Inki,
I love your patch! Yet something to improve:
[auto build test ERROR on drm-exynos/exynos-drm-next]
[also build test ERROR on drm-intel/for-linux-next drm-tip/drm-tip
tegra-drm/drm/tegra/for-next v5.13-rc3 next-20210525]
[cannot apply to drm/drm-next]
[If your patch is applied
On Tue, May 25, 2021 at 10:56 PM Yang Li wrote:
>
> Fix function name in sdma_v5_2.c kernel-doc comment
> to remove a warning found by clang_w1.
>
> drivers/gpu/drm/amd/amdgpu/sdma_v5_2.c:528: warning: expecting prototype
> for sdma_v_0_ctx_switch_enable(). Prototype was for
>
> > > > I think I would see if it's possible to call
> > > > vga_arb_select_default_device() from vga_arbiter_add_pci_device()
> > > > instead of from vga_arb_device_init().
> > > >
> > > > I would also (as a separate patch) try to get rid of this loop in
> > > > vga_arb_device_init():
> > > >
> >
Fix function name in sdma_v5_2.c kernel-doc comment
to remove a warning found by clang_w1.
drivers/gpu/drm/amd/amdgpu/sdma_v5_2.c:528: warning: expecting prototype
for sdma_v_0_ctx_switch_enable(). Prototype was for
sdma_v5_2_ctx_switch_enable() instead.
Reported-by: Abaci Robot
Signed-off-by:
Hi, Bjorn,
On Tue, May 25, 2021 at 9:55 PM Bjorn Helgaas wrote:
>
> On Tue, May 25, 2021 at 07:03:05PM +0800, Huacai Chen wrote:
> > On Thu, May 20, 2021 at 3:33 AM Bjorn Helgaas wrote:
> > > On Wed, May 19, 2021 at 10:17:14AM +0800, Huacai Chen wrote:
> > > > On Wed, May 19, 2021 at 3:35 AM
Applied. Thanks!
Alex
On Tue, May 25, 2021 at 3:51 AM Shaokun Zhang
wrote:
>
> Function 'r300_mc_wait_for_idle' and 'r600_mc_wait_for_idle'
> are declared twice, remove the repeated declaration.
>
> Cc: Alex Deucher
> Cc: "Christian König"
> Signed-off-by: Shaokun Zhang
> ---
>
On Tue, May 25, 2021 at 8:33 AM Shaokun Zhang
wrote:
>
> Function 'evergreen_print_gpu_status_regs' is declared twice, remove
> the repeated declaration.
>
> Cc: Alex Deucher
> Cc: "Christian König"
> Signed-off-by: Shaokun Zhang
Applied. Thanks!
Alex
> ---
>
On Tue, May 25, 2021 at 6:51 AM Shaokun Zhang
wrote:
>
> Function 'dc_power_down_on_boot' is declared twice, remove the
> repeated declaration.
>
> Cc: Harry Wentland
> Cc: Leo Li
> Cc: Alex Deucher
> Signed-off-by: Shaokun Zhang
Applied. Thanks!
Alex
> ---
>
On 25/05/2021 00:57, abhin...@codeaurora.org wrote:
On 2021-05-16 13:29, Dmitry Baryshkov wrote:
The IRQ table in the dpu_hw_interrupts.h is big, ugly, and hard to
maintain. There are only few interrupts used from that table. Newer
generations use different IRQ locations. Move this data to hw
a note.
And when submitting 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/Sam-McNally/drm-dp_mst-Add-self-tests-for-up-requests/20210525-090214
base: git://anongit.freedesktop.org/drm/drm-tip drm-tip
On 25/05/2021 14:29, Guenter Roeck wrote:
The result of container_of() operations is never NULL unless the embedded
element is the first element of the structure. This is not the case here.
The NULL checks on the result of container_of() are therefore unnecessary
and misleading. Remove them.
On 07/04/2021 16:06, Bernard Zhao wrote:
This patch fix coccicheck warning:
drivers/gpu/drm/msm/dp/dp_link.c:848:5-8: Unneeded variable: "ret". Return "0"
on line 880
Also remove unneeded function return value check.
Signed-off-by: Bernard Zhao
Reviewed-by: Dmitry Baryshkov
---
On Wed, 12 May 2021 at 03:05, Daniel Vetter wrote:
>
> On Tue, May 11, 2021 at 10:31:39AM +0200, Zbigniew Kempczyński wrote:
> > We have established previously we stop using relocations starting
> > from gen12 platforms with Tigerlake as an exception. Unfortunately
> > we need extend transition
This patch is analogous to the previous sync file export patch in that
it allows you to import a sync_file into a dma-buf. Unlike the previous
patch, however, this does add genuinely new functionality to dma-buf.
Without this, the only way to attach a sync_file to a dma-buf is to
submit a batch
This adds a new "DMA Buffer ioctls" section to the dma-buf docs and adds
documentation for DMA_BUF_IOCTL_SYNC.
Signed-off-by: Jason Ekstrand
Cc: Daniel Vetter
Cc: Christian König
Cc: Sumit Semwal
---
Documentation/driver-api/dma-buf.rst | 8 +++
include/uapi/linux/dma-buf.h | 32
For dma-buf sync_file import, we want to get all the fences on a
dma_resv plus one more. We could wrap the fence we get back in an array
fence or we could make dma_resv_get_singleton_unlocked take "one more"
to make this case easier.
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
Cc:
Modern userspace APIs like Vulkan are built on an explicit
synchronization model. This doesn't always play nicely with the
implicit synchronization used in the kernel and assumed by X11 and
Wayland. The client -> compositor half of the synchronization isn't too
bad, at least on intel, because we
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 (Jason Ekstrand):
- Take reference of fences both for creating the
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. This matches
the iterator behavior of dma_fence_chain_for_each in that it iterates
zero times if head == NULL.
-
None of these helpers actually leak any RCU details to the caller. They
all assume you have a genuine reference, take the RCU read lock, and
retry if needed. Naming them with an _rcu is likely to cause callers
more panic than needed.
v2 (Jason Ekstrand):
- Fix function argument indentation
Modern userspace APIs like Vulkan are built on an explicit
synchronization model. This doesn't always play nicely with the
implicit synchronization used in the kernel and assumed by X11 and
Wayland. The client -> compositor half of the synchronization isn't too
bad, at least on intel, because we
From: Michal Wajdeczko
We want to stop using guc.send_mutex while sending CTB messages
so we have to start protecting access to CTB send descriptor.
For completeness protect also CTB receive descriptor.
Add spinlock to struct intel_guc_ct_buffer and start using it.
Signed-off-by: Michal
From: Michal Wajdeczko
We are no longer using descriptor to hold G2H replies and we are
protecting access to the descriptor and command buffer by the
separate spinlock, so we can stop using mutex.
Signed-off-by: Michal Wajdeczko
Signed-off-by: Matthew Brost
Reviewed-by: Matthew Brost
---
From: Michal Wajdeczko
In upcoming patch we will allow more CTB requests to be sent in
parallel to the GuC for procesing, so we shouldn't assume any more
that GuC will always reply without 10ms.
Use bigger value from CONFIG_DRM_I915_GUC_CTB_TIMEOUT instead.
v2: Add
Ensure H2G buffer updates are visible before descriptor tail updates by
inserting a barrier between the H2G buffer update and the tail. The
barrier is simple wmb() for SMEM and is register write for LMEM. This is
needed if more than 1 H2G can be inflight at once.
Signed-off-by: Matthew Brost
Cc:
From: Michal Wajdeczko
Future GuC will require CTB buffers sizes to be multiple of 4K.
Make these changes now as this shouldn't impact us too much.
Signed-off-by: Michal Wajdeczko
Signed-off-by: Matthew Brost
Reviewed-by: Matthew Brost
Cc: John Harrison
---
From: Michal Wajdeczko
Stop using fence/status from CTB descriptor as future GuC ABI will
no longer support replies over CTB descriptor.
Signed-off-by: Michal Wajdeczko
Signed-off-by: Matthew Brost
Reviewed-by: Matthew Brost
---
.../gt/uc/abi/guc_communication_ctb_abi.h | 4 +-
From: Michal Wajdeczko
Since most of future CT traffic will be based on G2H requests,
instead of copying incoming CT message to static buffer and then
create new allocation for such request, always copy incoming CT
message to new allocation. Also by doing it while reading CT
header, we can
From: Michal Wajdeczko
Upcoming GuC firmware will always require just two CTBs and we
also plan to configure them with different sizes, so definining
them as array is no longer suitable.
Signed-off-by: Michal Wajdeczko
Signed-off-by: Matthew Brost
Reviewed-by: Matthew Brost
---
From: Michal Wajdeczko
In upcoming GuC firmware, CTB size will be removed from the CTB
descriptor so we must keep it locally for any calculations.
While around, improve some debug messages and helpers.
Signed-off-by: Michal Wajdeczko
Signed-off-by: Matthew Brost
Reviewed-by: Matthew Brost
From: Michal Wajdeczko
We can retrieve offsets to cmds buffers and descriptor from
actual pointers that we already keep locally.
Signed-off-by: Michal Wajdeczko
Signed-off-by: Matthew Brost
Reviewed-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 16 ++--
1
From: Michal Wajdeczko
In irq handler try to receive just single G2H message, let other
messages to be received from tasklet.
Signed-off-by: Michal Wajdeczko
Signed-off-by: Matthew Brost
Reviewed-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 67 ---
From: Michal Wajdeczko
Generic helpers should be placed in i915_utils.h.
Signed-off-by: Michal Wajdeczko
Signed-off-by: Matthew Brost
Reviewed-by: Matthew Brost
---
drivers/gpu/drm/i915/i915_utils.h | 5 +
drivers/gpu/drm/i915/i915_vma.h | 5 -
2 files changed, 5 insertions(+), 5
From: Daniele Ceraolo Spurio
In GuC submission mode the CS is owned by the GuC FW, so all CS status
interrupts are handled by it. We only need the user interrupt as that
signals request completion.
Since we're now starting the engines directly in GuC submission mode
when selected, we can stop
From: Daniele Ceraolo Spurio
We have a couple of failure injection points in the CT enablement path,
so we need to use i915_probe_error() to select the appropriate log level.
A new macro (CT_PROBE_ERROR) has been added to the set of CT logging
macros to be used in this scenario and upcoming
From: Michal Wajdeczko
Our fwif.h file is now mix of strict firmware ABI definitions and
set of our helpers. In anticipation of upcoming changes to the GuC
interface try to keep them separate in smaller maintainable files.
Signed-off-by: Michal Wajdeczko
Signed-off-by: Matthew Brost
From: Rodrigo Vivi
This action is no-op in the GuC side for a few versions already
and it is getting entirely removed soon, in an upcoming version.
Time to remove before we face communication issues.
Cc: Vinay Belgaumkar
Signed-off-by: Rodrigo Vivi
Signed-off-by: Matthew Brost
Acked-by:
From: Daniele Ceraolo Spurio
If we're about to sanitize the GuC, something might have going wrong
beforehand, so we should avoid trying to talk to it. Even if GuC is
still running fine, the sanitize will reset its internal state and clear
the CTB registration, so there is still no need to
As discussed in [1] we are breaking that large series into a several
smaller ones. This series is the non-interface changing part of step #2
- it makes all the changes needed before updating the GuC firwmare to a
new version without breaking any old interfaces.
A follow on series will be squashed
Hi Daniele,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-tip/drm-tip]
[cannot apply to drm-intel/for-linux-next char-misc/char-misc-testing v5.13-rc3
next-20210525]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting
https://bugzilla.kernel.org/show_bug.cgi?id=213211
Bug ID: 213211
Summary: kernel BUG at drivers/gpu/drm/qxl/qxl_display.c:293!
Product: Drivers
Version: 2.5
Kernel Version: 4.12.6
Hardware: All
OS: Linux
On 25.05.2021 20:15, Matthew Brost wrote:
> On Thu, May 06, 2021 at 12:13:32PM -0700, Matthew Brost wrote:
>> From: Michal Wajdeczko
>>
>> In irq handler try to receive just single G2H message, let other
>> messages to be received from tasklet.
>>
>> Signed-off-by: Michal Wajdeczko
>>
Am 2021-05-25 um 8:47 a.m. schrieb Dan Carpenter:
> If amdgpu_gem_prime_export() fails, then this code accidentally
> returns zero/success instead of a negative error code.
>
> Fixes: 190f2d7696c8 ("drm/amdgpu: Add DMA mapping of GTT BOs")
> Signed-off-by: Dan Carpenter
Thank you for catching
On 25.05.2021 20:08, Matthew Brost wrote:
> On Thu, May 06, 2021 at 12:13:29PM -0700, Matthew Brost wrote:
>> From: Michal Wajdeczko
>>
>> In upcoming patch we will allow more CTB requests to be sent in
>> parallel to the GuC for procesing, so we shouldn't assume any more
>> that GuC will
On Tue, May 25, 2021 at 9:19 PM Jason Ekstrand wrote:
>
> On Tue, May 25, 2021 at 10:37 AM Daniel Vetter wrote:
> >
> > On Mon, May 24, 2021 at 03:59:54PM -0500, Jason Ekstrand wrote:
> > > This patch is analogous to the previous sync file export patch in that
> > > it allows you to import a
On Tue, May 25, 2021 at 10:37 AM Daniel Vetter wrote:
>
> On Mon, May 24, 2021 at 03:59:54PM -0500, Jason Ekstrand wrote:
> > This patch is analogous to the previous sync file export patch in that
> > it allows you to import a sync_file into a dma-buf. Unlike the previous
> > patch, however,
Problem:
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:332:1: warning: unused label 'exit'
[-Wunused-label]
exit:
^
Fix: Put #ifdef CONFIG_64BIT around exit
Reported-by: kernel test robot
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 ++
1 file changed,
* Alistair Popple [210524 09:29]:
> The behaviour of try_to_unmap_one() is difficult to follow because it
> performs different operations based on a fairly large set of flags used
> in different combinations.
>
> TTU_MUNLOCK is one such flag. However it is exclusively used by
> try_to_munlock()
> -Original Message-
> From: Intel-gfx On Behalf Of
> Daniele Ceraolo Spurio
> Sent: Monday, May 24, 2021 10:48 PM
> To: intel-...@lists.freedesktop.org
> Cc: Vetter, Daniel ; Huang Sean Z
> ; dri-devel@lists.freedesktop.org; Chris Wilson
> ; Kondapally Kalyan
> ; Bommu, Krishnaiah
>
On 2021-05-25 05:22, Shaokun Zhang wrote:
Function 'dp_catalog_audio_enable' is declared twice, remove the
repeated declaration.
Cc: Rob Clark
Cc: Abhinav Kumar
Signed-off-by: Shaokun Zhang
Reviewed-by: Abhinav Kumar
---
drivers/gpu/drm/msm/dp/dp_catalog.h | 1 -
1 file changed, 1
On 2021-05-24 20:20, Guenter Roeck wrote:
The result of container_of() operations is never NULL unless the
embedded
element is the first element of the structure. This is not the case
here.
The NULL check on the result of container_of() is therefore unnecessary
and misleading. Remove it.
This
On Thu, May 06, 2021 at 12:13:33PM -0700, Matthew Brost wrote:
> From: Michal Wajdeczko
>
> Since most of future CT traffic will be based on G2H requests,
> instead of copying incoming CT message to static buffer and then
> create new allocation for such request, always copy incoming CT
>
On Thu, May 06, 2021 at 12:13:32PM -0700, Matthew Brost wrote:
> From: Michal Wajdeczko
>
> In irq handler try to receive just single G2H message, let other
> messages to be received from tasklet.
>
> Signed-off-by: Michal Wajdeczko
> Signed-off-by: Matthew Brost
> ---
>
On Thu, May 06, 2021 at 12:13:29PM -0700, Matthew Brost wrote:
> From: Michal Wajdeczko
>
> In upcoming patch we will allow more CTB requests to be sent in
> parallel to the GuC for procesing, so we shouldn't assume any more
> that GuC will always reply without 10ms.
>
> Use bigger value from
On Tue, May 25, 2021 at 11:16:12AM +0100, Tvrtko Ursulin wrote:
>
> On 06/05/2021 20:14, Matthew Brost wrote:
> > From: John Harrison
> >
> > The serial number tracking of engines happens at the backend of
> > request submission and was expecting to only be given physical
> > engines. However,
On Tue, May 25, 2021 at 07:48:12PM +0200, Noralf Trønnes wrote:
> > It's tedious to review this all the time, and my audit showed that
> > arcpgu actually forgot to set this.
> >
> > Make this the default and stop worrying.
> >
> > Again I sprinkled WARN_ON_ONCE on top to make sure we don't have
>
> It's tedious to review this all the time, and my audit showed that
> arcpgu actually forgot to set this.
>
> Make this the default and stop worrying.
>
> Again I sprinkled WARN_ON_ONCE on top to make sure we don't have
> strange combinations of hooks: cleanup_fb without prepare_fb doesn't
> make
On Mon, May 24, 2021 at 03:31:25PM +0200, Michal Wajdeczko wrote:
>
>
> On 06.05.2021 21:13, Matthew Brost wrote:
> > CTB writes are now in the path of command submission and should be
> > optimized for performance. Rather than reading CTB descriptor values
> > (e.g. head, tail, size) which
On Mon, May 24, 2021 at 01:59:54PM +0200, Michal Wajdeczko wrote:
>
>
> On 06.05.2021 21:13, Matthew Brost wrote:
> > Improve the error message when a unsolicited CT response is received by
> > printing fence that couldn't be found, the last fence, and all requests
> > with a response
On Mon, May 24, 2021 at 02:21:42PM +0200, Michal Wajdeczko wrote:
>
>
> On 06.05.2021 21:13, Matthew Brost wrote:
> > Add non blocking CTB send function, intel_guc_send_nb. In order to
> > support a non blocking CTB send function a spin lock is needed to
>
> spin lock was added in 16/97
>
> >
On Tue, May 25, 2021 at 10:21:00AM +0100, Tvrtko Ursulin wrote:
>
> On 06/05/2021 20:13, Matthew Brost wrote:
> > Add non blocking CTB send function, intel_guc_send_nb. In order to
> > support a non blocking CTB send function a spin lock is needed to
> > protect the CTB descriptors fields. Also
On Tue, May 25, 2021 at 10:24:09AM +0100, Tvrtko Ursulin wrote:
>
> On 06/05/2021 20:13, Matthew Brost wrote:
> > With the introduction of non-blocking CTBs more than one CTB can be in
> > flight at a time. Increasing the size of the CTBs should reduce how
> > often software hits the case where
Hi,
On Tue, May 25, 2021 at 12:31 AM Rajeev Nandan wrote:
>
> Add Samsung 13.3" FHD eDP AMOLED panel.
>
> Signed-off-by: Rajeev Nandan
> ---
>
> Changes in v4:
> - New
>
> drivers/gpu/drm/panel/panel-simple.c | 34 ++
> 1 file changed, 34 insertions(+)
>
> diff
Hi,
On Tue, May 25, 2021 at 12:31 AM Rajeev Nandan wrote:
>
> Add Samsung 13.3" FHD eDP AMOLED panel.
>
> Signed-off-by: Rajeev Nandan
> ---
>
> Changes in v4:
> - New
>
> Documentation/devicetree/bindings/display/panel/panel-simple.yaml | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git
Hi,
On Tue, May 25, 2021 at 12:31 AM Rajeev Nandan wrote:
>
> Some panels datasheets may specify a delay between the enable GPIO and
> the regulator. Support this in panel-simple.
>
> Signed-off-by: Rajeev Nandan
> ---
>
> Changes in v4:
> - New
>
> drivers/gpu/drm/panel/panel-simple.c | 23
Hi,
On Tue, May 25, 2021 at 12:31 AM Rajeev Nandan wrote:
>
> @@ -171,6 +172,19 @@ struct panel_desc {
>
> /** @connector_type: LVDS, eDP, DSI, DPI, etc. */
> int connector_type;
> +
> + /**
> +* @uses_dpcd_backlight: Panel supports eDP dpcd backlight control.
> +
On Tue, May 25, 2021 at 10:43:32AM +0100, Tvrtko Ursulin wrote:
>
> On 06/05/2021 20:13, Matthew Brost wrote:
> > Implement GuC submission tasklet for new interface. The new GuC
> > interface uses H2G to submit contexts to the GuC. Since H2G use a single
> > channel, a single tasklet submits is
Hi Dmitry,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v5.13-rc3 next-20210525]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base
On Tue 30 Mar 10:31 CDT 2021, Will Deacon wrote:
> On Tue, Mar 30, 2021 at 08:03:36AM -0700, Rob Clark wrote:
> > On Tue, Mar 30, 2021 at 2:34 AM Will Deacon wrote:
> > >
> > > On Mon, Mar 29, 2021 at 09:02:50PM -0700, Rob Clark wrote:
> > > > On Mon, Mar 29, 2021 at 7:47 AM Will Deacon wrote:
On Tue, May 25, 2021 at 11:06:00AM +0100, Tvrtko Ursulin wrote:
>
> On 06/05/2021 20:14, Matthew Brost wrote:
> > When running the GuC the GPU can't be considered idle if the GuC still
> > has contexts pinned. As such, a call has been added in
> > intel_gt_wait_for_idle to idle the UC and in turn
On Tue, May 25, 2021 at 10:52:01AM +0100, Tvrtko Ursulin wrote:
>
> On 06/05/2021 20:14, Matthew Brost wrote:
> > Disable semaphores when using GuC scheduling as semaphores are broken in
> > the current GuC firmware.
>
> What is "current"? Given that the patch itself is like year and a half old.
On Tue, May 25, 2021 at 03:07:06PM +0200, Michal Wajdeczko wrote:
>
>
> On 25.05.2021 04:53, Matthew Brost wrote:
> > On Thu, May 06, 2021 at 12:13:26PM -0700, Matthew Brost wrote:
> >> From: Michal Wajdeczko
> >>
> >> We can retrieve offsets to cmds buffers and descriptor from
> >> actual
On Tue, May 25, 2021 at 04:15:15PM +0200, Michal Wajdeczko wrote:
>
>
> On 24.05.2021 20:35, Matthew Brost wrote:
> > On Mon, May 24, 2021 at 02:58:12PM +0200, Michal Wajdeczko wrote:
> >>
> >>
> >> On 06.05.2021 21:13, Matthew Brost wrote:
> >>> Implement a stall timer which fails H2G CTBs once
On Tue, May 25, 2021 at 11:32:26AM +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
On Thu, May 06, 2021 at 12:13:31PM -0700, Matthew Brost wrote:
> From: Michal Wajdeczko
>
> We are no longer using descriptor to hold G2H replies and we are
> protecting access to the descriptor and command buffer by the
> separate spinlock, so we can stop using mutex.
>
> Signed-off-by: Michal
On Tue 25 May 06:29 CDT 2021, Guenter Roeck wrote:
> The result of container_of() operations is never NULL unless the embedded
> element is the first element of the structure. This is not the case here.
> The NULL checks on the result of container_of() are therefore unnecessary
> and misleading.
On Tue 25 May 07:22 CDT 2021, Shaokun Zhang wrote:
> Function 'dp_catalog_audio_enable' is declared twice, remove the
> repeated declaration.
>
> Cc: Rob Clark
> Cc: Abhinav Kumar
Reviewed-by: Bjorn Andersson
> Signed-off-by: Shaokun Zhang
> ---
> drivers/gpu/drm/msm/dp/dp_catalog.h | 1 -
On Fri, May 21, 2021 at 04:09:13PM +0200, Noralf Trønnes wrote:
>
>
> Den 21.05.2021 11.09, skrev Daniel Vetter:
> > Goes through all the drivers and deletes the default hook since it's
> > the default now.
> >
> > Signed-off-by: Daniel Vetter
>
> Acked-by: Noralf Trønnes
Can you perhaps
On Tue, May 25, 2021 at 04:27:49PM +0100, Tvrtko Ursulin wrote:
>
> On 25/05/2021 14:56, Daniel Vetter wrote:
> > On Fri, May 21, 2021 at 11:32:12AM -0700, Matthew Brost wrote:
> > > As discussed in [1] start merging some support patches as a precursor to
> > > GuC submission the i915. This is
On Tue, May 25, 2021 at 03:56:56PM +0200, Daniel Vetter wrote:
> On Fri, May 21, 2021 at 11:32:12AM -0700, Matthew Brost wrote:
> > 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]
On Tue, 25 May 2021 15:23:44 +0200,
Maxime Ripard wrote:
>
> In some situations, like a codec probe, we need to provide an IEC status
> default but don't have access to the sampling rate and width yet since
> no stream has been configured yet.
>
> Each and every driver has its own default,
On Tue, 25 May 2021 15:23:43 +0200,
Maxime Ripard wrote:
>
> The doc currently mentions that the IEC958 Playback Default should be
> exposed on the PCM iface, and the Playback Mask on the mixer iface.
>
> It's a bit confusing to advise to have two related controls on two
> separate ifaces, and
Am 25.05.21 um 14:38 schrieb Daniel Vetter:
On Mon, May 24, 2021 at 03:04:35PM -0500, Jason Ekstrand wrote:
On Fri, May 21, 2021 at 12:48 PM Daniel Vetter wrote:
On Thu, May 20, 2021 at 02:00:05PM -0500, Jason Ekstrand wrote:
Add a helper function to get a single fence representing
all
Am 25.05.21 um 12:07 schrieb Thomas Hellström:
On Tue, 2021-05-25 at 10:58 +0100, Matthew Auld wrote:
On Tue, 25 May 2021 at 10:32, Thomas Hellström
wrote:
On 5/25/21 11:18 AM, Matthew Auld wrote:
On Fri, 21 May 2021 at 16:33, Thomas Hellström
wrote:
The internal ttm_bo_util memcpy
On Tue, May 25, 2021 at 11:27 AM Christian König
wrote:
>
> Am 24.05.21 um 20:48 schrieb Alex Deucher:
> > Applied. Thanks!
>
> Ok, that's unfortunate.
>
> IIRC we added the code because of a different compiler warning.
>
I can revert it.
Alex
> Christian.
>
> >
> > Alex
> >
> > On Mon, May
On Fri, May 14, 2021 at 12:31 PM Jason Ekstrand wrote:
>
> 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
On Mon, May 24, 2021 at 03:59:54PM -0500, Jason Ekstrand wrote:
> This patch is analogous to the previous sync file export patch in that
> it allows you to import a sync_file into a dma-buf. Unlike the previous
> patch, however, this does add genuinely new functionality to dma-buf.
> Without
On Sat 01 May 20:42 CDT 2021, Caleb Connolly wrote:
> Resetting the panel on fajita causes it to never come back, we aren't
> quite sure why this is so for now lets remove reset handling as it is
> effectively broken. It is also not needed on enchilada.
>
> Signed-off-by: Caleb Connolly
> ---
>
On 25/05/2021 14:56, Daniel Vetter wrote:
On Fri, May 21, 2021 at 11:32:12AM -0700, Matthew Brost wrote:
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/
Am 24.05.21 um 20:48 schrieb Alex Deucher:
Applied. Thanks!
Ok, that's unfortunate.
IIRC we added the code because of a different compiler warning.
Christian.
Alex
On Mon, May 24, 2021 at 6:47 AM Jiapeng Chong
wrote:
In the function amdgpu_uvd_cs_msg(), every branch in the switch
On 5/25/2021 6:23 AM, Maxime Ripard wrote:
> From: Dom Cobley
>
> Enable NO_WAIT_RESP, DMA_WIDE_SOURCE, DMA_WIDE_DEST, and bump the DMA
> panic and AXI priorities to avoid any DMA transfer error with HBR audio
> (8 channel, 192Hz).
>
> Signed-off-by: Dom Cobley
> Signed-off-by: Maxime
On Mon, May 24, 2021 at 03:59:53PM -0500, Jason Ekstrand wrote:
> For dma-buf sync_file import, we want to get all the fences on a
> dma_resv plus one more. We could wrap the fence we get back in an array
> fence or we could make dma_resv_get_singleton_unlocked take "one more"
> to make this case
On Tue, May 25, 2021 at 5:05 PM Christian König
wrote:
>
> Hi Daniel,
>
> Am 25.05.21 um 15:05 schrieb Daniel Vetter:
> > Hi Christian,
> >
> > On Sat, May 22, 2021 at 10:30:19AM +0200, Christian König wrote:
> >> Am 21.05.21 um 20:31 schrieb Daniel Vetter:
> >> This works by adding the fence of
Met vriendelijke groet / kind regards,
Mike Looijmans
System Expert
TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands
T: +31 (0) 499 33 69 69
E: mike.looijm...@topicproducts.com
W: www.topic.nl
Please consider the environment before printing this e-mail
On
Something I forgot to add is that patches 1 to 4 already have a
Reviewed-by: Christian König
Am 25.05.21 um 17:10 schrieb Thomas Zimmermann:
Implement mmap via struct drm_gem_object_functions.mmap in amdgpu,
radeon and nouveau. This allows for using common DRM helpers for
the mmap-related
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
for drivers that already have "drm" in their name:
$ cat /proc/fb
0 rockchipdrmdrmfb
$ cat /proc/fb
0 simpledrmdrmfb
Also, there isn't a lot of
The function ttm_bo_mmap is unused. Remove it and it's helpers; including
the verify_access callback in struct ttm_device_funcs.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo_vm.c | 53 -
The vmwgfx driver is the only remaining user of ttm_bo_mmap(). Inline
the code. The internal helper ttm_bo_vm_lookup() is now also part of
vmwgfx as vmw_bo_vm_lookup().
v2:
* replace pr_err() with drm_err() (Zack)
Signed-off-by: Thomas Zimmermann
Reviewed-by: Zack Rusin
---
1 - 100 of 219 matches
Mail list logo
