On Sun, May 1, 2022 at 11:41 PM Linus Walleij wrote:
>
> (...)
> > +static struct gpiod_lookup_table hx4700_audio_gpio_table = {
> > + .dev_id = "hx4700-audio",
> > + .table = {
> > + GPIO_LOOKUP("gpio-pxa", GPIO75_HX4700_EARPHONE_nDET,
> > + "ea
On 20/04/2022 20:13, Matthew Auld wrote:
Add an entry for the new uapi needed for small BAR on DG2+.
v2:
- Some spelling fixes and other small tweaks. (Akeem & Thomas)
- Rework error capture interactions, including no longer needing
NEEDS_CPU_ACCESS for objects marked for capture. (Th
On Mon, 2 May 2022 at 02:56, Abhinav Kumar wrote:
>
>
>
> On 5/1/2022 1:06 PM, Marijn Suijten wrote:
> > On 2022-04-30 12:25:57, Abhinav Kumar wrote:
> >>
> >>
> >> On 4/30/2022 11:58 AM, Marijn Suijten wrote:
> >>> On 2022-04-30 20:55:33, Dmitry Baryshkov wrote:
> The downstream uses read-mo
On Mon, 2 May 2022 at 04:38, Abhinav Kumar wrote:
>
> Looks like our new CI has given all the answers we need :) which is a
> great win for the CI in my opinion.
>
> Take a look at this report :
> https://gitlab.freedesktop.org/drm/msm/-/jobs/22015361
>
> This issue seems to be because this change
On Mon, 2 May 2022 at 08:39, Abhinav Kumar wrote:
>
> Add missing break statement for dpu_hw_ctl_update_pending_flush_wb().
> Otherwise this leads to below build warning.
>
> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c:273:2:
> warning: unannotated fall-through between switch labels
>de
Move the initializer for the mode variable to the declaration point to
remove unitialized variable access from the DEBUG_DPU macro. This fixes
the following warning:
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c:250:37: note: initialize
the variable 'mode' to silence this warning
Fixes: d7
On Mon, 02 May 2022, Kefeng Wang wrote:
> Use IOMEM_ERR_PTR() instead of self defined IO_ERR_PTR().
>
> Signed-off-by: Kefeng Wang
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/i915_vma.c | 4 ++--
> drivers/gpu/drm/i915/i915_vma.h | 1 -
> 2 files changed, 2 insertions(+), 3 deletion
On 2022-05-01 16:56:45, Abhinav Kumar wrote:
> [snip]
> Wouln't this macro already make sure that 'reg' doesnt have anything in
> the top 16 bits? Its doing a & with 0x3f00
Like I said, it is unlikely that this happens, only if someone starts
changing the code that assigns to `reg` which is u
On 2022-05-02 01:44:20, Dmitry Baryshkov wrote:
> [sni[
> > In any case, given that you've already sent this patch and another three
> > patches [2] fixing/cleaning up the series tells me it's far from ready.
> > Most of this should just be handled - or have been handled - in review
> > and amended
Hello,
This series contain patches suggested by Thomas Zimmermannas a feedback for
"[RFC PATCH v4 00/11] Fix some race between sysfb device registration and
drivers probe" [0].
Since other changes in [0] were more controversial, I decided to just split
this part in a new patch-set and revisit the
The drm_fbdev_generic_setup() function already sets the preferred bits per
pixel for the device to dev->mode_config.preferred_depth, if preferred_bpp
value is zero.
Passing the same value to the function is unnecessary. Let's cleanup that
in the two drivers that do it.
Signed-off-by: Javier Marti
By default the bits per pixel for the emulated framebuffer device is set
to dev->mode_config.preferred_depth, but some devices need another value.
Since this second parameter is only used by a few drivers, and to allow
drivers to use it for passing other configurations when registering the
fbdev,
Indicate to fbdev subsystem that the registered framebuffer is provided by
the system firmware, so that it can handle accordingly. For example, would
unregister the FB devices if asked to remove the conflicting framebuffers.
Add a new DRM_FB_FW field to drm_fbdev_generic_setup() options parameter.
On 02/05/2022 10:54, Lionel Landwerlin wrote:
On 20/04/2022 20:13, Matthew Auld wrote:
Add an entry for the new uapi needed for small BAR on DG2+.
v2:
- Some spelling fixes and other small tweaks. (Akeem & Thomas)
- Rework error capture interactions, including no longer needing
NEEDS
On 02/05/2022 11:43, Marijn Suijten wrote:
On 2022-05-02 01:44:20, Dmitry Baryshkov wrote:
[sni[
In any case, given that you've already sent this patch and another three
patches [2] fixing/cleaning up the series tells me it's far from ready.
Most of this should just be handled - or have been ha
On 02/05/2022 11:34, Marijn Suijten wrote:
On 2022-05-01 16:56:45, Abhinav Kumar wrote:
[snip]
Wouln't this macro already make sure that 'reg' doesnt have anything in
the top 16 bits? Its doing a & with 0x3f00
Like I said, it is unlikely that this happens, only if someone starts
changing t
Hi Javier
Am 02.05.22 um 10:48 schrieb Javier Martinez Canillas:
Hello,
This series contain patches suggested by Thomas Zimmermannas a feedback for
"[RFC PATCH v4 00/11] Fix some race between sysfb device registration and
drivers probe" [0].
Since other changes in [0] were more controversial,
Hello Thomas,
On 5/2/22 12:35, Thomas Zimmermann wrote:
> Hi Javier
>
> Am 02.05.22 um 10:48 schrieb Javier Martinez Canillas:
>> Hello,
>>
>> This series contain patches suggested by Thomas Zimmermannas a feedback for
Ups, I missed a space here. I meant to write "Zimmermann as a feedback..."
>
Few bug fixes for lrc selftest.
v4:
Gen8 don't have per engine recording of BB_OFFSET [Chris]
Chris Wilson (4):
drm/i915/gt: Explicitly clear BB_OFFSET for new contexts
drm/i915/selftests: Check for incomplete LRI from the context image
drm/i915/selftest: Always cancel semaphore on error
From: Chris Wilson
Even though the initial protocontext we load onto HW has the register
cleared, by the time we save it into the default image, BB_OFFSET has
had the enable bit set. Reclear BB_OFFSET for each new context.
Testcase: igt/i915_selftests/gt_lrc
v2:
Extend it for gen8.
v3:
BB_O
From: Chris Wilson
When testing whether we can get the GPU to leak information about
non-privileged state, we first need to ensure that the output buffer is
set to a known value as the HW may opt to skip the write into memory for
a non-privileged read of a sensitive register. We chose POISON_INUS
From: Chris Wilson
In order to keep the context image parser simple, we assume that all
commands follow a similar format. A few, especially not MI commands on
the render engines, have fixed lengths not encoded in a length field.
This caused us to incorrectly skip over 3D state commands, and start
From: Chris Wilson
Ensure that we always signal the semaphore when timing out, so that if it
happens to be stuck waiting for the semaphore we will quickly recover
without having to wait for a reset.
Reported-by: CQ Tang
Signed-off-by: Chris Wilson
Cc: CQ Tang
cc: Joonas Lahtinen
Signed-off-b
Hi Javier,
Thank you for the patch.
On Mon, May 02, 2022 at 10:48:29AM +0200, Javier Martinez Canillas wrote:
> By default the bits per pixel for the emulated framebuffer device is set
> to dev->mode_config.preferred_depth, but some devices need another value.
>
> Since this second parameter is
On Fri, 29 Apr 2022, "Murthy, Arun R" wrote:
>> +static int output_bpc_show(struct seq_file *m, void *data) {
>
> Can we have a meaningful name instead of 'm' ?
> Upon changing this parameter name, you can have my
> Reviewed-By: Arun R Murthy
Please keep 'm'. It's by far the most common name for
On 2022-05-02 at 16:40:00 +0530, Ramalingam C wrote:
> From: Chris Wilson
>
> Even though the initial protocontext we load onto HW has the register
> cleared, by the time we save it into the default image, BB_OFFSET has
> had the enable bit set. Reclear BB_OFFSET for each new context.
>
> Testca
Hello,
This small series contains fixes for two bugs I found in fbmem.c, that may
explain a bug reported in the rpi4 [0] when using simplefb and vc4 drivers.
I was not able to reproduce the mentioned bug, but looking at the code I
think that it might explain the issue.
I've tested these patches
If real driver probes, the fbdev core kicks out all drivers that are using
a framebuffer that were provided by the system firmware. But it could be a
user-space process still has a file descriptor for the fbdev device node.
This can lead to a NULL pointer dereference, if the framebuffer device is
A reference to the framebuffer device struct fb_info is stored in the file
private data, but this reference could no longer be valid and must not be
accessed directly. Instead, the file_fb_info() accessor function must be
used since it does sanity checking to make sure that the fb_info is valid.
T
Am 02.05.22 um 15:09 schrieb Javier Martinez Canillas:
A reference to the framebuffer device struct fb_info is stored in the file
private data, but this reference could no longer be valid and must not be
accessed directly. Instead, the file_fb_info() accessor function must be
used since it does
Hi
Am 02.05.22 um 15:09 schrieb Javier Martinez Canillas:
If real driver probes, the fbdev core kicks out all drivers that are using
a framebuffer that were provided by the system firmware. But it could be a
user-space process still has a file descriptor for the fbdev device node.
This can lead
Hello Laurent,
On 5/2/22 13:34, Laurent Pinchart wrote:
> Hi Javier,
>
> Thank you for the patch.
>
Thanks a lot for your feedback.
[snip]
>> +++ b/drivers/gpu/drm/drm_fb_helper.c
>> @@ -2501,8 +2501,16 @@ static const struct drm_client_funcs
>> drm_fbdev_client_funcs = {
>> /**
>> * drm_
On Fri-29-04-2022 08:02 pm, Murthy, Arun R wrote:
-Original Message-
From: Intel-gfx On Behalf Of
Bhanuprakash Modem
Sent: Monday, April 11, 2022 3:21 PM
To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; amd-
g...@lists.freedesktop.org; jani.nik...@linux.intel.com;
Hello Thomas,
On 5/2/22 15:26, Thomas Zimmermann wrote:
> Hi
>
> Am 02.05.22 um 15:09 schrieb Javier Martinez Canillas:
>> If real driver probes, the fbdev core kicks out all drivers that are using
>> a framebuffer that were provided by the system firmware. But it could be a
>> user-space process
On 2022-05-02 09:28, Modem, Bhanuprakash wrote:
> On Fri-29-04-2022 08:02 pm, Murthy, Arun R wrote:
>>
>>
>>> -Original Message-
>>> From: Intel-gfx On Behalf Of
>>> Bhanuprakash Modem
>>> Sent: Monday, April 11, 2022 3:21 PM
>>> To: intel-...@lists.freedesktop.org; dri-devel@lists.free
Hello Thomas,
On 5/2/22 15:20, Thomas Zimmermann wrote:
>
>
> Am 02.05.22 um 15:09 schrieb Javier Martinez Canillas:
>> A reference to the framebuffer device struct fb_info is stored in the file
>> private data, but this reference could no longer be valid and must not be
>> accessed directly. In
A reference to the framebuffer device struct fb_info is stored in the file
private data, but this reference could no longer be valid and must not be
accessed directly. Instead, the file_fb_info() accessor function must be
used since it does sanity checking to make sure that the fb_info is valid.
T
In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
not being declared. We thus need to add HAS_IOPORT as dependency for
those drivers using them and guard inline code in headers.
Co-developed-by: Arnd Bergmann
Signed-off-by: Niklas Schnelle
---
drivers/video/fbdev/Kconfig |
On 28.04.22 11:27, Juergen Gross wrote:
Hello Juergen, all
Simplify drmfront's ring creation and removal via xenbus_setup_ring()
and xenbus_teardown_ring().
Signed-off-by: Juergen Gross
I am not familiar with DRM bits of this driver, but a little bit
familiar with Xen bits this patch on
In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
not being declared. We thus need to add HAS_IOPORT as dependency for
those drivers using them. In the bochs driver there is optional MMIO
support detected at runtime, warn if this isn't taken when
HAS_IOPORT is not defined.
The
Fix spelling typo in comments.
Signed-off-by: pengfuyuan
---
drivers/gpu/drm/radeon/atombios.h | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/radeon/atombios.h
b/drivers/gpu/drm/radeon/atombios.h
index bd5dc09e860f..da35a970fcc0 100644
--- a/drive
Hi Christian,
On Thu, 28 Apr 2022 at 13:33, Christian König wrote:
>
> Am 28.04.22 um 08:39 schrieb Yuanzheng Song:
> > 'cat /sys/kernel/debug/dma_buf/bufinfo' will print the Dma-buf
> > Objects' information when the CONFIG_DEBUG_FS=y.
> > However, the printed table header information does not co
On Fri, 2022-04-29 at 15:50 +0200, Niklas Schnelle wrote:
> In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
> not being declared. We thus need to add HAS_IOPORT as dependency for
> those drivers using them. There is also a direct and hard coded use in
> cirrus.c which accordi
On Fri, 2022-04-29 at 15:50 +0200, Niklas Schnelle wrote:
> In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
> not being declared. We thus need to add HAS_IOPORT as dependency for
> those drivers using them and guard inline code in headers.
>
> Co-developed-by: Arnd Bergmann
In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
not being declared. We thus need to add HAS_IOPORT as dependency for
those drivers using them and guard inline code in headers.
Co-developed-by: Arnd Bergmann
Signed-off-by: Niklas Schnelle
---
drivers/video/fbdev/Kconfig |
On Fri, 2022-04-29 at 18:33 -0100, Melissa Wen wrote:
> I've been contributing to v3d through improvements, reviews, testing,
> debugging, etc. So, I'm adding myself as a co-maintainer of the V3D
> driver.
>
Acked-by: Juan A. Suarez
In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
not being declared. We thus need to add HAS_IOPORT as dependency for
those drivers using them. There is also a direct and hard coded use in
cirrus.c which according to the comment is only necessary during resume.
Let's just skip
Capture the impact of memory region preference list of the objects, on
their memory residency and Flat-CCS capability.
v2:
Fix the Flat-CCS capability of an obj with {lmem, smem} preference
list [Thomas]
v3:
Reworded the doc [Matt]
Signed-off-by: Ramalingam C
cc: Matthew Auld
cc: Thomas H
Flat-CCS eviction enhancements
v3:
Incorporated the review suggestions [Matt]
Ramalingam C (3):
drm/i915/gt: BUG_ON unexpected NULL at scatterlist walking
drm/i915/gt: optimize the ccs_sz calculation per chunk
drm/i915/gt: Document the eviction of the Flat-CCS objects
drivers/gpu/drm/i9
Calculate the ccs_sz that needs to be emitted based on the src
and dst pages emitted per chunk. And handle the return value of emit_pte
for the ccs pages.
v2:
ccs_sz moved to the reduced scope [Matt]
Signed-off-by: Ramalingam C
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/gt/intel_migr
While locating the start of ccs scatterlist in smem scatterlist, that has
to be the size of lmem obj size + corresponding ccs data size, report bug
if scatterlist terminate before that length.
v2:
s/GEM_BUG_ON/BUG_ON with more commenting [Matt]
v3:
Converted GEM_BUG_ON into BUG_ON with more do
Capture the eviction details for Flat-CCS capable, lmem objects.
v2:
Fix the Flat-ccs capbility of lmem obj with smem residency
possibility [Thomas]
v3:
Fixed the suggestions [Matt]
Signed-off-by: Ramalingam C
cc: Thomas Hellstrom
cc: Matthew Auld
Reviewed-by: Matthew Auld
---
drivers/
Add a mutex lock to protect concurrent access to I/O registers
against each other. This happens between invokataion of commit-
tail functions and get-mode operations. Both with use the CRTC
index registers MGA1064_GEN_IO_DATA and MGA1064_GEN_IO_CTL.
Concurrent access can lead to failed mode-setting
Add a mutex lock to protect concurrent access to I/O registers
against each other. This happens between invokataion of commit-
tail functions and get-mode operations. Both with use the CRTC
index register AST_IO_CRTC_PORT. Concurrent access can lead to
failed mode-setting operations.
Signed-off-by
Protect access to I/O registers in ast and mgag200 via lock. Commit-
tail functions and get-modes operations use the same registers and can
interfere with each other. This can result in failed mode-setting
operations.
As both drivers use fully managed cleanup, the patchset adds a new helper
that i
Add drmm_mutex_init(), a helper that provides managed mutex cleanup. The
mutex will be destroyed with the final reference of the DRM device.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_managed.c | 27 +++
include/drm/drm_managed.h | 3 +++
2 files change
On Mon-02-05-2022 07:08 pm, Harry Wentland wrote:
On 2022-05-02 09:28, Modem, Bhanuprakash wrote:
On Fri-29-04-2022 08:02 pm, Murthy, Arun R wrote:
-Original Message-
From: Intel-gfx On Behalf Of
Bhanuprakash Modem
Sent: Monday, April 11, 2022 3:21 PM
To: intel-...@lists.freedeskt
On 2022-05-02 10:27, Modem, Bhanuprakash wrote:
> On Mon-02-05-2022 07:08 pm, Harry Wentland wrote:
>>
>>
>> On 2022-05-02 09:28, Modem, Bhanuprakash wrote:
>>> On Fri-29-04-2022 08:02 pm, Murthy, Arun R wrote:
> -Original Message-
> From: Intel-gfx On Behalf Of
>
On Fri, 29 Apr 2022 at 11:49, Jagan Teki wrote:
>
> Hi Robert,
>
> Can you apply this?
>
Thanks for the reminder.
Applied to drm-misc-next.
> On Thu, Mar 31, 2022 at 8:22 PM Robert Foss wrote:
> >
> > On Thu, 31 Mar 2022 at 16:50, Jagan Teki wrote:
> > >
> > > + Robert
> > >
> > > On Tue, Feb
Hi
Am 06.12.21 um 02:38 schrieb Kuo-Hsiang Chou:
I'm not going to merge this patch. As I said, I don't think it fixes the
problem. Mouse movement and resolution switching should not interfere with each
other. The DRM framework should guarantee that.
OK, thanks for your confirmation.
I cannot
On Mon, 25 Apr 2022 at 15:44, Pin-Yen Lin wrote:
>
> Send DPCD SET_POWER command to downstream in .atomic_disable to make the
> downstream monitor enter the power down mode, so the device suspend won't
> be affected.
>
> Fixes: b5c84a9edcd418 ("drm/bridge: add it6505 driver")
> Signed-off-by: Pin-
friendly ping.
I am not even myself completely convinced that this is the correct
patch and it might just workaround some issues, but list_debug.c does
check if a list was already deleted and throws an error if it was and
this patch indeed fixes this one issue as multiple threads could enter
__i91
On Sat, 23 Apr 2022 at 14:09, Alvin Šipraga wrote:
>
> From: Alvin Šipraga
>
> Changes:
>
> v1->v2:
> - add Robert's r-b
> - fix up 'case XXX...YYY+14' statements to read nicer in the 2nd patch
>
>
> We have an ADV7535 which is nominally supported by this driver. These
> two patches fix up th
On Tue, 26 Apr 2022 at 21:37, Marek Vasut wrote:
>
> The i.MX8MP contains two syscon registers which are responsible
> for configuring the on-SoC DPI-to-LVDS serializer. Add DT binding
> which represents this serializer as a bridge.
>
> Acked-by: Sam Ravnborg
> Signed-off-by: Marek Vasut
> Cc: L
On Thu, 28 Apr 2022 at 20:08, Laurent Pinchart
wrote:
>
> Hi Uwe,
>
> Thank you for the patch.
>
> On Thu, Apr 28, 2022 at 06:28:03PM +0200, Uwe Kleine-König wrote:
> > tfp410_fini() always returns zero. Make it return no value which makes it
> > easier to see in the callers that there is no error
Hi Paul,
On 5/1/2022 2:08 AM, Paul Menzel wrote:
Dear Richard,
Sorry for the late reply.
Am 26.04.22 um 15:53 schrieb Gong, Richard:
On 4/21/2022 12:35 AM, Paul Menzel wrote:
Am 21.04.22 um 03:12 schrieb Gong, Richard:
On 4/20/2022 3:29 PM, Paul Menzel wrote:
Am 19.04.22 um 23:46 sc
On Wed, 27 Apr 2022 at 12:55, Mike Lothian wrote:
>
> On Tue, 26 Apr 2022 at 17:36, Christian König
> wrote:
> >
> > Hi Mike,
> >
> > sounds like somehow stitching together the SG table for PRIME doesn't
> > work any more with this patch.
> >
> > Can you try with P2P DMA disabled?
>
> -CONFIG_PC
Hi Paul,
On 5/1/2022 2:14 AM, Paul Menzel wrote:
Dear Richard,
Am 29.04.22 um 18:06 schrieb Richard Gong:
Active State Power Management (ASPM) feature is enabled since kernel
5.14.
There are some AMD Volcanic Islands (VI) GFX cards, such as the
WX3200 and
RX640, that do not work with ASPM-en
By default the bits per pixel for the emulated framebuffer device is set
to dev->mode_config.preferred_depth, but some devices need another value.
Since this second parameter is only used by a few drivers, and to allow
drivers to use it for passing other configurations when registering the
fbdev,
Hello,
This series contain patches suggested by Thomas Zimmermann as a feedback for
"[RFC PATCH v4 00/11] Fix some race between sysfb device registration and
drivers probe" [0].
Since other changes in [0] were more controversial, I decided to just split
this part in a new patch-set and revisit th
Indicate to fbdev subsystem that the registered framebuffer is provided by
the system firmware, so that it can handle accordingly. For example, would
unregister the FB devices if asked to remove the conflicting framebuffers.
Add a new DRM_FB_FW field to drm_fbdev_generic_setup() options parameter.
The drm_fbdev_generic_setup() function already sets the preferred bits per
pixel for the device to dev->mode_config.preferred_depth, if preferred_bpp
value is zero.
Passing the same value to the function is unnecessary. Let's cleanup that
in the two drivers that do it.
Signed-off-by: Javier Marti
On Fri, 29 Apr 2022, Jeffrey Hugo wrote:
> DEFINE_DRM_GEM_FOPS() references drm functions from other headers. For
> example drm_open() is defined in drm_file.h and drm_ioctl() is defined
> in drm_ioctl.h. Since drm_gem.h doesn't include these headers, it
> relies on an implicit include from the
On 5/2/2022 8:41 PM, Mike Lothian wrote:
On Wed, 27 Apr 2022 at 12:55, Mike Lothian wrote:
On Tue, 26 Apr 2022 at 17:36, Christian König wrote:
Hi Mike,
sounds like somehow stitching together the SG table for PRIME doesn't
work any more with this patch.
Can you try with P2P DMA disabled?
Hi Javier,
Thank you for the patch.
On Mon, May 02, 2022 at 05:38:58PM +0200, Javier Martinez Canillas wrote:
> The drm_fbdev_generic_setup() function already sets the preferred bits per
> pixel for the device to dev->mode_config.preferred_depth, if preferred_bpp
> value is zero.
>
> Passing the
Hi Javier,
Thank you for the patch.
On Mon, May 02, 2022 at 05:38:59PM +0200, Javier Martinez Canillas wrote:
> By default the bits per pixel for the emulated framebuffer device is set
> to dev->mode_config.preferred_depth, but some devices need another value.
>
> Since this second parameter is
On 5/2/2022 1:05 AM, Dmitry Baryshkov wrote:
On Mon, 2 May 2022 at 04:38, Abhinav Kumar wrote:
Looks like our new CI has given all the answers we need :) which is a
great win for the CI in my opinion.
Take a look at this report :
https://gitlab.freedesktop.org/drm/msm/-/jobs/22015361
This
Hi Javier,
Thank you for the patch.
On Mon, May 02, 2022 at 05:39:00PM +0200, Javier Martinez Canillas wrote:
> Indicate to fbdev subsystem that the registered framebuffer is provided by
> the system firmware, so that it can handle accordingly. For example, would
> unregister the FB devices if as
On 5/2/2022 1:24 AM, Dmitry Baryshkov wrote:
Move the initializer for the mode variable to the declaration point to
remove unitialized variable access from the DEBUG_DPU macro. This fixes
the following warning:
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c:250:37: note: initialize
the
On Fri, Apr 29, 2022 at 02:28:20PM -0600, Alex Williamson wrote:
> On Thu, 21 Apr 2022 13:28:38 -0300
> Jason Gunthorpe wrote:
>
> > When the open_device() op is called the container_users is incremented and
> > held incremented until close_device(). Thus, so long as drivers call
> > functions wi
On 4/30/22 07:23, Arnd Bergmann wrote:
On Sat, Apr 30, 2022 at 3:32 PM Arnd Bergmann wrote:
On Sat, Apr 30, 2022 at 2:41 PM Guenter Roeck wrote:
On 4/30/22 01:04, Arnd Bergmann wrote:
and concluded that it must have done this for a long time. In my own qemu
instance, I see a crash from iWMM
On Mon, 2 May 2022 at 16:54, Arunpravin Paneer Selvam
wrote:
>
>
>
> On 5/2/2022 8:41 PM, Mike Lothian wrote:
> > On Wed, 27 Apr 2022 at 12:55, Mike Lothian wrote:
> >> On Tue, 26 Apr 2022 at 17:36, Christian König
> >> wrote:
> >>> Hi Mike,
> >>>
> >>> sounds like somehow stitching together th
Ponte Vecchio (PVC) is a new GPU based on the Xe_HPC architecture. As a
compute-focused platform, PVC has compute engines and enhanced copy
engines, but no render engine (there is no geometry pipeline) and no
display.
This is just a handful of early enablement patches, including some
initial supp
From: John Harrison
PVC adds extra blitter engines (in the following patch). The reset
selftest has a local array on the stack which is sized by the number
of engines. The increase pushes the size of this array to the point
where it trips the 'stack too large' compile warning. This patch takes
th
From: Ayaz A Siddiqui
Bspec: 45101, 72161
Signed-off-by: Ayaz A Siddiqui
Signed-off-by: Fei Yang
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_gt_types.h| 1 +
drivers/gpu/drm/i915/gt/intel_mocs.c| 24 -
drivers/gpu/drm/i915/gt/intel_workarounds.
The SoC registers, including RP_STATE_CAP, have moved to a new location
in GTTMMADR on Ponte Vecchio. We need to update the register offset
accordingly.
Cc: Rodrigo Vivi
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_rps.c | 4 +++-
drivers/gpu/drm/i915/i915_reg.h | 1 +
2 fil
From: Stuart Summers
Additional blitter and media engines will be enabled later.
Bspec: 44481, 44482
Signed-off-by: Stuart Summers
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/i915_pci.c | 21 +
drivers/gpu/d
Add PVC's forcewake ranges.
Bspec: 67609
Cc: Daniele Ceraolo Spurio
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/intel_uncore.c | 150 +-
drivers/gpu/drm/i915/selftests/intel_uncore.c | 2 +
2 files changed, 151 insertions(+), 1 deletion(-)
diff --git a/driver
This patch adds the interrupt handler support for
new copy engines.
Bspec: 54030
Original-author: CQ Tang
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_gt_irq.c | 16
drivers/gpu/drm/i915/gt/intel_gt_regs.h | 4
2 files changed, 20 insertions(+)
diff --git
From: Stuart Summers
Although we already strip 3D-specific flags from PIPE_CONTROL
instructions when submitting to a compute engine, there are some
additional flags that need to be removed when the platform as a whole
lacks a 3D pipeline. Add those restrictions here.
Bspec: 47112
Signed-off-by:
This patch adds the reset support for new copy engines
in PVC.
Bspec: 52549
Original-author: CQ Tang
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 8 +
drivers/gpu/drm/i915/gt/intel_gt_regs.h | 44 +--
2 files changed, 34 insertions(+), 18 d
This patch adds the basic definitions needed to support
new copy engines. Also updating the cmd_info to accommodate
new engines, as the engine id's of legacy engines have been
changed.
Original-author: CQ Tang
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c| 56 ++
From: Lucas De Marchi
As we have more copy engines now, mask all of them from aux table
invalidate.
Cc: Prathap Kumar Valsan
Signed-off-by: Lucas De Marchi
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
From: Lucas De Marchi
The new Link Copy engines in PVC may be fused off according to the
mslice_mask. Each bit of the MEML3_EN_MASK we read from the
GEN10_MIRROR_FUSE3 register disables a pair of link copy engines.
Bspec: 44483
Cc: Matt Roper
Signed-off-by: Lucas De Marchi
Signed-off-by: Matt
Hello everyone,
it's a well known problem that the DMA-buf subsystem mixed synchronization and
memory management requirements into the same dma_fence and dma_resv objects.
Because of this dma_fence objects need to guarantee that they complete within a
finite amount of time or otherwise the syst
Start introducing a new part of the framework for handling user fences.
In strict opposition to normal fences user fences don't reliable finish in
a fixed amount of time and therefore can't be used as dependency in memory
management.
Because of this user fences are marked with DMA_FENCE_FLAG_USER
This is supposed to be used by device drivers.
Signed-off-by: Christian König
---
drivers/gpu/drm/i915/i915_request.h | 2 +-
drivers/gpu/drm/i915/i915_sw_fence_work.h | 2 +-
drivers/gpu/drm/nouveau/nouveau_fence.c | 4 ++--
include/linux/dma-fence.h | 4 ++--
4 files ch
When any of the fences inside the array is an user fence the whole array
is considered to be an user fence as well.
Signed-off-by: Christian König
---
drivers/dma-buf/dma-fence-array.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/dma-buf/dma-fence-array.c
If either the previous fence or the newly chained on is an user fence the
dma_fence chain node is considered an user fence as well.
This way the user fence status propagates through the chain.
Signed-off-by: Christian König
---
drivers/dma-buf/dma-fence-chain.c | 4
1 file changed, 4 inser
This patch adds the new DMA_RESV_USAGE_USER flag to the dma_resv object
which must be used with user fence objects.
In opposite to the other usage flags this one doesn't automatically return
other lower classes. So when user fences are requested from the dma_resv
object only user fences are return
1 - 100 of 198 matches
Mail list logo
