On Tue, Sep 27, 2022 at 03:12:00PM -0400, Hamza Mahfooz wrote:
> Address the following error:
> drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_stream.c: In function
> ‘dc_stream_remove_writeback’:
> drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_stream.c:527:55: error:
> array subscript [0,
Hi All,
The latest mainline kernel branch fails to build allmodconfig for every
ARCH with gcc-11 with the error:
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_stream.c: In function
'dc_stream_remove_writeback':
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_stream.c:527:83: error: array
On 06/10/2022 04:04, allen wrote:
> From: allen chen
>
> Add properties to restrict dp output data-lanes and clock.
>
> Signed-off-by: Pin-Yen Lin
> Signed-off-by: Allen Chen
> ---
> .../bindings/display/bridge/ite,it6505.yaml | 12
> 1 file changed, 12 insertions(+)
>
Hi Zack
Am 05.10.22 um 21:49 schrieb Zack Rusin:
Hi, Thomas.
Because you've been the one who's been working on drm_fb_helper.c the most the
last
few years I wanted to pick your brain a bit.
I was porting vmwgfx to drm_fb_helper code which is largely trivial, just
removing
all of vmwgfx_fb.c
On Tue, Oct 4, 2022 at 10:35 PM Dmitry Torokhov
wrote:
> > Dmitry, could you fix this? Just patch away in gpiolib-of.c.
>
> Sure, I'll add a few quirks. I wonder what is the best way to merge
> this? I can create a bunch of IBs to be pulled, or I can send quirks to
> you/Bartosz and once they
Hi all,
On Thu, 6 Oct 2022 09:28:10 +1100 Stephen Rothwell
wrote:
>
> I have applied the following hack for today:
>
> From: Stephen Rothwell
> Date: Thu, 6 Oct 2022 09:14:26 +1100
> Subject: [PATCH] fix up for drivers/gpu/drm/amd/display/dc/core/dc_stream.c
>
> Signed-off-by: Stephen
Add constants for the registers the contain various display-mode
parameters and update the mode-setting function. No functional
changes.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez Canillas
---
drivers/gpu/drm/udl/udl_modeset.c | 102 ++
Add style fixes, better error handling and reporting, and minor
clean-up changes to the connector code before moving the code to
the rest of the modesetting pipeline.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez Canillas
---
drivers/gpu/drm/udl/udl_connector.c | 64
Add constants for the various commands that the driver can send to
the device and update the respective helper functions. No functional
changes.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez Canillas
---
drivers/gpu/drm/udl/udl_drv.h | 10 --
Remove the empty function udl_simple_display_pipe_mode_valid() and
let simple-KMS helpers accept the modes. No functional changes.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez Canillas
---
drivers/gpu/drm/udl/udl_modeset.c | 8
1 file changed, 8 deletions(-)
diff
Add register constants for the video lock. No functional changes.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez Canillas
---
drivers/gpu/drm/udl/udl_modeset.c | 4 ++--
drivers/gpu/drm/udl/udl_proto.h | 5 +
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git
Move the connector next to the rest of the modesetting code. No
functional changes.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez Canillas
---
drivers/gpu/drm/udl/Makefile| 2 +-
drivers/gpu/drm/udl/udl_connector.c | 132
Add register constants for the framebuffer scanout addresses and
update the related helper functions. No functional changes.
v2:
* extract address bytes with helper macros (Javier)
* fix comments
Signed-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez Canillas
---
Move the existing register constants to a new file in preparation of
adding more of them. Renaming is intentional. No functional changes.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez Canillas
---
drivers/gpu/drm/udl/udl_drv.h | 9 -
The sku_pixel_limit is a per-device property, similar to the amount
of available video memory. Move the respective mode-valid test from
the connector to the mode-config structure.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez Canillas
---
drivers/gpu/drm/udl/udl_connector.c |
Add drm_dev_enter() and drm_dev_exit() to the various modesetting
functions that interact with the device. After hot-unplugging the
device, these functions will return early. So far, the udl driver
relied on USB interfaces to handle unplugging of the device.
Signed-off-by: Thomas Zimmermann
Add the register constants for setting the color depth. The driver
only uses 16bpp. No functional changes.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez Canillas
---
drivers/gpu/drm/udl/udl_modeset.c | 2 +-
drivers/gpu/drm/udl/udl_proto.h | 3 +++
2 files changed, 4
Use a damage iterator to process damage areas individually. Merging
damage areas can result in large updates of unchanged framebuffer
regions. As USB is rather slow, it's better to process damage areas
individually and hence minimize USB-transfered data.
As part of the change, move
Set the USB control-message timeout to the USB default of 5 seconds.
Done for consistency with other uses of usb_control_msg() in udl and
other drivers.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez Canillas
---
drivers/gpu/drm/udl/udl_connector.c | 2 +-
1 file changed, 1
Remove the _drm_ infix from struct udl_drm_connector and introduce a
macro for upcasting from struct drm_connector. No functional changes.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez Canillas
---
drivers/gpu/drm/udl/udl_connector.c | 19 +--
Inline a modesetting helper in the CRTC's enable function. Build the
command set directly in the USB URB's buffer and drop an intermediate
buffer. No functional changes.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez Canillas
---
drivers/gpu/drm/udl/udl_drv.h | 3 --
On Thu, Oct 06, 2022 at 11:03:15AM +0200, Linus Walleij wrote:
> On Tue, Oct 4, 2022 at 10:35 PM Dmitry Torokhov
> wrote:
>
> > > Dmitry, could you fix this? Just patch away in gpiolib-of.c.
> >
> > Sure, I'll add a few quirks. I wonder what is the best way to merge
> > this? I can create a bunch
On Thu, Oct 06, 2022 at 07:05:48AM -0600, Jason A. Donenfeld wrote:
> > > diff --git a/drivers/infiniband/ulp/ipoib/ipoib_cm.c
> > > b/drivers/infiniband/ulp/ipoib/ipoib_cm.c
> > > index fd9d7f2c4d64..a605cf66b83e 100644
> > > --- a/drivers/infiniband/ulp/ipoib/ipoib_cm.c
> > > +++
With no callers left of prandom_u32() and prandom_bytes(), remove these
deprecated wrappers.
Reviewed-by: Kees Cook
Signed-off-by: Jason A. Donenfeld
---
include/linux/prandom.h | 12
1 file changed, 12 deletions(-)
diff --git a/include/linux/prandom.h b/include/linux/prandom.h
The prandom_u32() function has been a deprecated inline wrapper around
get_random_u32() for several releases now, and compiles down to the
exact same code. Replace the deprecated wrapper with a direct call to
the real function.
Reviewed-by: Kees Cook
Signed-off-by: Jason A. Donenfeld
---
The prandom_bytes() function has been a deprecated inline wrapper around
get_random_bytes() for several releases now, and compiles down to the
exact same code. Replace the deprecated wrapper with a direct call to
the real function.
Reviewed-by: Kees Cook
Signed-off-by: Jason A. Donenfeld
---
Rather than incurring a division or requesting too many random bytes for
the given range, use the prandom_u32_max() function, which only takes
the minimum required bytes from the RNG and avoids divisions.
Reviewed-by: Kees Cook
Reviewed-by: KP Singh
Reviewed-by: Christoph Böhmwalder
Rather than truncate a 32-bit value to a 16-bit value or an 8-bit value,
simply use the get_random_{u8,u16}() functions, which are faster than
wasting the additional bytes from a 32-bit value.
Reviewed-by: Kees Cook
Signed-off-by: Jason A. Donenfeld
---
crypto/testmgr.c
On Wed, Oct 05, 2022 at 04:03:56PM -0600, Alex Williamson wrote:
> We can't have a .remove callback that does nothing, this breaks
> removing the device while it's in use. Once we have the
> vfio_unregister_group_dev() fix below, we'll block until the device is
> unused, at which point
On Thu, Oct 06, 2022 at 07:05:48AM -0600, Jason A. Donenfeld wrote:
> On Thu, Oct 6, 2022 at 6:47 AM Jason Gunthorpe wrote:
> > On Wed, Oct 05, 2022 at 11:48:42PM +0200, Jason A. Donenfeld wrote:
...
> > > - u32 isn = (prandom_u32() & ~7UL) - 1;
> > > + u32 isn = (get_random_u32() &
On Thu, Oct 6, 2022 at 7:25 AM Jason A. Donenfeld wrote:
> This is a five part treewide cleanup of random integer handling.
> [...]
> Please take a look!
I should add that this patchset probably appears bigger than it
already is, due in part to that wall of motivational text. Keep in
mind,
This looks good to me. Care to add you s-o-b?
Alex
On Thu, Oct 6, 2022 at 4:12 AM Stephen Rothwell wrote:
>
> Hi all,
>
> On Thu, 6 Oct 2022 09:28:10 +1100 Stephen Rothwell
> wrote:
> >
> > I have applied the following hack for today:
> >
> > From: Stephen Rothwell
> > Date: Thu, 6 Oct 2022
On 05/10/2022 19:48, John Harrison wrote:
On 10/3/2022 05:00, Tvrtko Ursulin wrote:
On 03/10/2022 08:53, Tvrtko Ursulin wrote:
On 30/09/2022 18:44, John Harrison wrote:
On 9/30/2022 02:22, Tvrtko Ursulin wrote:
On 29/09/2022 17:21, John Harrison wrote:
On 9/29/2022 00:42, Tvrtko Ursulin
Hi Dave, Daniel,
Some fixes for the merge window - one EHL MOCS table fix and the rest is
in the display area around modifier handling and PSR on Gen12+, one fixup
for g4x+ and one fixing recent fastset refactoring.
Regards,
Tvrtko
drm-intel-next-fixes-2022-10-06-1:
- Round to closest in g4x+
On Wed, 07 Sep 2022, Jilin Yuan wrote:
> Delete the redundant word 'on'.
>
> Signed-off-by: Jilin Yuan
Thanks for the patch, pushed to drm-misc-next.
BR,
Jani.
> ---
> drivers/gpu/drm/drm_edid.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git
On Thu, 06 Oct 2022 10:04:43 +0800, allen wrote:
> From: allen chen
>
> Add properties to restrict dp output data-lanes and clock.
>
> Signed-off-by: Pin-Yen Lin
> Signed-off-by: Allen Chen
> ---
> .../bindings/display/bridge/ite,it6505.yaml | 12
> 1 file changed, 12
On Wed, Oct 5, 2022 at 9:05 PM allen wrote:
>
> From: allen chen
>
> Add properties to restrict dp output data-lanes and clock.
>
> Signed-off-by: Pin-Yen Lin
> Signed-off-by: Allen Chen
> ---
> .../bindings/display/bridge/ite,it6505.yaml | 12
> 1 file changed, 12
On Wed, Oct 05, 2022 at 02:17:17PM -0600, Alex Williamson wrote:
> > diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c
> > b/drivers/gpu/drm/i915/gvt/kvmgt.c
> > index 41bba40feef8f4..9003145adb5a93 100644
> > --- a/drivers/gpu/drm/i915/gvt/kvmgt.c
> > +++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
> > @@
Remove the redundant semicolon
Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=2333
Reported-by: Abaci Robot
Signed-off-by: Yang Li
---
drivers/gpu/drm/i915/gvt/vgpu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gvt/vgpu.c
Hi Marek,
On Thu, Oct 6, 2022 at 2:21 AM Marek Szyprowski
wrote:
>
> Hi Jagan,
>
> On 05.10.2022 17:12, Jagan Teki wrote:
> > This series supports common bridge support for Samsung MIPI DSIM
> > which is used in Exynos and i.MX8MM SoC's.
> >
> > The final bridge supports both the Exynos and
On Thu, Oct 06, 2022 at 04:58:28AM +0800, kernel test robot wrote:
> tree/branch:
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
> branch HEAD: 67ae4f7434cee86ee318d46fb10b8a9840ad2e81 Add linux-next
> specific files for 20221005
>
> Error/Warning reports:
>
>
On Wed, Oct 05, 2022 at 09:55:43PM -0700, Kees Cook wrote:
> If any of the subsystems ask you to break this up (I hope not), I've got
> this[1], which does a reasonable job of splitting a commit up into
> separate commits for each matching subsystem.
[1]
On Wed 05-10-22 23:48:42, Jason A. Donenfeld wrote:
> The prandom_u32() function has been a deprecated inline wrapper around
> get_random_u32() for several releases now, and compiles down to the
> exact same code. Replace the deprecated wrapper with a direct call to
> the real function.
>
>
I have a DRM master implementing a purpose-built compositor for a dedicated
use-case. It drives several different connectors, each on its own vsync cadence
(there's no clone mode happening here).
The goal is to have commits to each connector occur completely without respect
to whatever is
[Posting v2 right away, because I CC'd too many people for v1, and email
systems worldwide exploded.]
Hi folks,
This is a five part treewide cleanup of random integer handling. The
rules for random integers are:
- If you want a secure or an insecure random u64, use get_random_u64().
- If you
Current dual mode adaptor ("DP++") detection code assumes that all
adaptors support i2c sub-addressing for read operations from the
DP-HDMI adaptor ID buffer. It has been observed that multiple
adaptors do not in fact support this, and always return data starting
at register 0. On affected
Replace simple-KMS helpers with regular atomic-modesetting helpers.
The simple-KMS helpers introduce a mid-layer abstraction without
added functionality. Using regular atomic helpers makes the driver's
implementation more discoverable and simplifies code sharing.
The conversion effectively
This patchset reworks the udl driver's modesetting code.
Patches #1 to #5 improve the connector code with various updates.
Patches #6 to #10 improve the modesetting code. Patch #7 replaces the
simple-KMS helpers with the regular atomic helpers. Patch #9 adds DRM
hot-unplugging. The driver had
On Fri, Mar 4, 2022 at 8:48 PM Dave Stevenson
wrote:
>
> Mapping to the drm_bridge flag pre_enable_upstream_first,
> add a new flag prepare_upstream_first to drm_panel to allow
> the panel driver to request that the upstream bridge should
> be pre_enabled before the panel prepare.
>
>
Hi Robert
Thanks for the review.
On 10/4/2022 8:55 AM, Robert Foss wrote:
On Mon, 29 Aug 2022 at 20:23, Abhinav Kumar wrote:
adv7533 bridge tries to dynamically switch lanes based on the
mode by detaching and attaching the mipi dsi device.
This approach is incorrect because this method of
FYI, v3, which I'll wait a bit before posting, will also take care of
get_random_int().
If intel_gvt_dma_map_guest_page failed, it will call
ppgtt_invalidate_spt, which will finally free the spt.
But the caller does not notice that, it will free spt again in error path.
Fix this by spliting invalidate and free in ppgtt_invalidate_spt.
Only free spt when in good case.
Reported-by:
Le 06/10/2022 à 18:53, Jason A. Donenfeld a écrit :
> The prandom_bytes() function has been a deprecated inline wrapper around
> get_random_bytes() for several releases now, and compiles down to the
> exact same code. Replace the deprecated wrapper with a direct call to
> the real function.
>
>
On Wed, Oct 05, 2022 at 11:46:15PM -0700, Guenter Roeck wrote:
> On Tue, Sep 27, 2022 at 03:12:00PM -0400, Hamza Mahfooz wrote:
> > Address the following error:
> > drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_stream.c: In function
> > ‘dc_stream_remove_writeback’:
> >
Le 06/10/2022 à 19:24, Jason A. Donenfeld a écrit :
> Hi Christophe,
>
> On Thu, Oct 6, 2022 at 11:21 AM Christophe Leroy
> wrote:
>> Le 06/10/2022 à 18:53, Jason A. Donenfeld a écrit :
>>> The prandom_u32() function has been a deprecated inline wrapper around
>>> get_random_u32() for several
Le 06/10/2022 à 19:31, Christophe Leroy a écrit :
Le 06/10/2022 à 19:24, Jason A. Donenfeld a écrit :
Hi Christophe,
On Thu, Oct 6, 2022 at 11:21 AM Christophe Leroy
wrote:
Le 06/10/2022 à 18:53, Jason A. Donenfeld a écrit :
The prandom_u32() function has been a deprecated inline
> On Oct 6, 2022, at 9:25 AM, Jason A. Donenfeld wrote:
>
> The prandom_u32() function has been a deprecated inline wrapper around
> get_random_u32() for several releases now, and compiles down to the
> exact same code. Replace the deprecated wrapper with a direct call to
> the real function.
Rather than incurring a division or requesting too many random bytes for
the given range, use the prandom_u32_max() function, which only takes
the minimum required bytes from the RNG and avoids divisions.
Reviewed-by: Kees Cook
Reviewed-by: KP Singh
Reviewed-by: Christoph Böhmwalder # for drbd
Rather than truncate a 32-bit value to a 16-bit value or an 8-bit value,
simply use the get_random_{u8,u16}() functions, which are faster than
wasting the additional bytes from a 32-bit value.
Reviewed-by: Kees Cook
Acked-by: Toke Høiland-Jørgensen # for sch_cake
Signed-off-by: Jason A.
The prandom_u32() function has been a deprecated inline wrapper around
get_random_u32() for several releases now, and compiles down to the
exact same code. Replace the deprecated wrapper with a direct call to
the real function. The same also applies to get_random_int(), which is
just a wrapper
The prandom_bytes() function has been a deprecated inline wrapper around
get_random_bytes() for several releases now, and compiles down to the
exact same code. Replace the deprecated wrapper with a direct call to
the real function.
Reviewed-by: Kees Cook
Signed-off-by: Jason A. Donenfeld
---
Changes v2->v3:
- Handle get_random_int() conversions too, which were overlooked before,
in the same way as the rest.
Hi folks,
This is a five part treewide cleanup of random integer handling. The
rules for random integers are:
- If you want a secure or an insecure random u64, use
With no callers left of prandom_u32() and prandom_bytes(), as well as
get_random_int(), remove these deprecated wrappers, in favor of
get_random_u32() and get_random_bytes().
Reviewed-by: Kees Cook
Signed-off-by: Jason A. Donenfeld
---
drivers/char/random.c | 11 +--
On 2022-10-06 04:12, Stephen Rothwell wrote:
Hi all,
On Thu, 6 Oct 2022 09:28:10 +1100 Stephen Rothwell
wrote:
I have applied the following hack for today:
From: Stephen Rothwell
Date: Thu, 6 Oct 2022 09:14:26 +1100
Subject: [PATCH] fix up for
On Thu 06-10-22 07:25:08, Jason A. Donenfeld wrote:
> The prandom_u32() function has been a deprecated inline wrapper around
> get_random_u32() for several releases now, and compiles down to the
> exact same code. Replace the deprecated wrapper with a direct call to
> the real function.
>
>
On Thu 06-10-22 07:25:06, Jason A. Donenfeld wrote:
> Rather than incurring a division or requesting too many random bytes for
> the given range, use the prandom_u32_max() function, which only takes
> the minimum required bytes from the RNG and avoids divisions.
>
> Reviewed-by: Kees Cook
>
Le 06/10/2022 à 18:53, Jason A. Donenfeld a écrit :
> The prandom_u32() function has been a deprecated inline wrapper around
> get_random_u32() for several releases now, and compiles down to the
> exact same code. Replace the deprecated wrapper with a direct call to
> the real function. The same
On Wed, Oct 5, 2022 at 1:51 PM Marek Szyprowski
wrote:
>
> Hi Jagan,
>
> On 05.10.2022 17:12, Jagan Teki wrote:
> > This series supports common bridge support for Samsung MIPI DSIM
> > which is used in Exynos and i.MX8MM SoC's.
> >
> > The final bridge supports both the Exynos and i.MX8MM DSI
We're observing sporadic HuC delayed load timeouts in CI, due to mei_pxp
binding completing later than we expected. HuC is still still loaded
when the bind occurs, but in the meantime i915 has started allowing
submission to the VCS engines even if HuC is not there.
In most of the cases I've
On Thu, Oct 06, 2022 at 11:33:14AM +0200, Simon Rettberg wrote:
> Current dual mode adaptor ("DP++") detection code assumes that all
> adaptors support i2c sub-addressing for read operations from the
> DP-HDMI adaptor ID buffer. It has been observed that multiple
> adaptors do not in fact support
Hi Christophe,
On Thu, Oct 6, 2022 at 11:21 AM Christophe Leroy
wrote:
> Le 06/10/2022 à 18:53, Jason A. Donenfeld a écrit :
> > The prandom_u32() function has been a deprecated inline wrapper around
> > get_random_u32() for several releases now, and compiles down to the
> > exact same code.
Hello Thomas,
On 10/5/22 13:40, Thomas Zimmermann wrote:
> In drm_atomic_helper_check_crtc_state(), do not add a new plane state
> to the global state if it does not exist already. Adding a new plane
> state will result in overhead for the plane during the atomic-commit
> step.
>
> For the test
On 10/5/22 13:40, Thomas Zimmermann wrote:
> Rename the atomic helper function drm_atomic_helper_check_crtc_state()
> to drm_atomic_helper_check_crtc_primary_plane() and only check for an
> attached primary plane. Adapt callers.
>
> Instead of having one big function to check for various CRTC
On Wed, Oct 05, 2022 at 08:59:43AM -0700, Vinay Belgaumkar wrote:
> Read the values stored in the SLPC structures. Remove the
> fields that are no longer valid (like RPS interrupts) as
> well.
>
> v2: Move all functionality changes to this patch (Jani)
> v3: Fix compile warning and if condition
From: John Harrison
An earlier patch added support for compute engines. However, it missed
enabling the anti-pre-emption w/a for the new engine class. So move
the 'compute capable' flag earlier and use it for the pre-emption w/a
test.
Fixes: c674c5b9342e ("drm/i915/xehp: CCS should use RCS
From: John Harrison
A workaround was added to the driver to allow compute workloads to run
'forever' by disabling pre-emption on the RCS engine for Gen12.
It is not totally unbound as the heartbeat will kick in eventually
and cause a reset of the hung engine.
However, this does not work well in
From: John Harrison
Compute workloads are inherently not pre-emptible on current hardware.
Thus the pre-emption timeout was disabled as a workaround to prevent
unwanted resets. Instead, the hang detection was left to the heartbeat
and its (longer) timeout. This is undesirable with GuC submission
From: John Harrison
GuC converts the pre-emption timeout and timeslice quantum values into
clock ticks internally. That significantly reduces the point of 32bit
overflow. On current platforms, worst case scenario is approximately
110 seconds. Rather than allowing the user to set higher values
From: John Harrison
Compute workloads are inherently not pre-emptible for long periods on
current hardware. As a workaround for this, the pre-emption timeout
for compute capable engines was disabled. This is undesirable with GuC
submission as it prevents per engine reset of hung contexts. Hence
On Thu, 6 Oct 2022 08:37:09 -0300
Jason Gunthorpe wrote:
> On Wed, Oct 05, 2022 at 04:03:56PM -0600, Alex Williamson wrote:
> > We can't have a .remove callback that does nothing, this breaks
> > removing the device while it's in use. Once we have the
> > vfio_unregister_group_dev() fix below,
On Thu, Oct 6, 2022 at 2:48 PM Linus Torvalds
wrote:
>
> On Tue, Oct 4, 2022 at 8:42 PM Dave Airlie wrote:
> >
> > Lots of stuff all over, some new AMD IP support and gang
> > submit support [..]
>
> Hmm.
>
> I have now had my main desktop lock up twice after pulling this.
> Nothing in the dmesg
On Thu, Oct 6, 2022 at 12:28 PM Alex Deucher wrote:
>
> Maybe you are seeing this which is an issue with GPU TLB flushes which
> is kind of sporadic:
> https://gitlab.freedesktop.org/drm/amd/-/issues/2113
Well, that seems to be 5.19, and while timing changes (or whatever
other software updates)
Hey Linus,
On 2022-10-06 15:39, Linus Torvalds wrote:
On Thu, Oct 6, 2022 at 1:51 AM Sudip Mukherjee (Codethink)
wrote:
This is only seen with gcc-11, gcc-12 builds are ok.
Hmm. This seems to be some odd gcc issue.
I *think* that what is going on is that the test
j = 0 ; j <
Hello,
syzbot found the following issue on:
HEAD commit:bbed346d5a96 Merge branch 'for-next/core' into for-kernelci
git tree: git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git
for-kernelci
console output: https://syzkaller.appspot.com/x/log.txt?x=13b7a1b888
kernel
On Thu, Oct 6, 2022 at 8:39 PM Linus Torvalds
wrote:
>
> On Thu, Oct 6, 2022 at 1:51 AM Sudip Mukherjee (Codethink)
> wrote:
> >
> > This is only seen with gcc-11, gcc-12 builds are ok.
>
> Hmm. This seems to be some odd gcc issue.
>
>
> The fix *MAY* be to just add a '&& i < MAX_DWB_PIPES'
On Fri, 7 Oct 2022 at 06:14, Alex Deucher wrote:
>
> On Thu, Oct 6, 2022 at 3:48 PM Linus Torvalds
> wrote:
> >
> > On Thu, Oct 6, 2022 at 12:28 PM Alex Deucher wrote:
> > >
> > > Maybe you are seeing this which is an issue with GPU TLB flushes which
> > > is kind of sporadic:
> > >
On Fri, 7 Oct 2022 at 07:41, Dave Airlie wrote:
>
> On Fri, 7 Oct 2022 at 06:24, Dave Airlie wrote:
> >
> > On Fri, 7 Oct 2022 at 06:14, Alex Deucher wrote:
> > >
> > > On Thu, Oct 6, 2022 at 3:48 PM Linus Torvalds
> > > wrote:
> > > >
> > > > On Thu, Oct 6, 2022 at 12:28 PM Alex Deucher
> >
On Fri, Oct 07, 2022 at 12:58:45AM +0800, Zheng Wang wrote:
> If intel_gvt_dma_map_guest_page failed, it will call
> ppgtt_invalidate_spt, which will finally free the spt.
> But the caller does not notice that, it will free spt again in error path.
>
> Fix this by spliting invalidate and free in
On Thu, Oct 6, 2022 at 1:51 AM Sudip Mukherjee (Codethink)
wrote:
>
> This is only seen with gcc-11, gcc-12 builds are ok.
Hmm. This seems to be some odd gcc issue.
I *think* that what is going on is that the test
j = 0 ; j < MAX_DWB_PIPES
makes gcc decide that "hey, j is in the range
On Thu, Oct 6, 2022 at 3:48 PM Linus Torvalds
wrote:
>
> On Thu, Oct 6, 2022 at 12:28 PM Alex Deucher wrote:
> >
> > Maybe you are seeing this which is an issue with GPU TLB flushes which
> > is kind of sporadic:
> > https://gitlab.freedesktop.org/drm/amd/-/issues/2113
>
> Well, that seems to be
On Thu, Oct 06, 2022 at 12:39:40PM -0700, Linus Torvalds wrote:
> What confuses me is that error message ("array subscript [0, 0] is
> outside array bounds of 'struct dc_writeback_info[1]') which seems to
> be aware that the value is actually 0.
I've seen bugs in the tracker where the reporting
On Thu, Oct 6, 2022 at 9:37 PM Kees Cook wrote:
>
> On Thu, Oct 06, 2022 at 12:39:40PM -0700, Linus Torvalds wrote:
> > What confuses me is that error message ("array subscript [0, 0] is
> > outside array bounds of 'struct dc_writeback_info[1]') which seems to
> > be aware that the value is
On Tue, Oct 4, 2022 at 8:42 PM Dave Airlie wrote:
>
> Lots of stuff all over, some new AMD IP support and gang
> submit support [..]
Hmm.
I have now had my main desktop lock up twice after pulling this.
Nothing in the dmesg after a reboot, and nothing in particular that
seems to trigger it, so
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: 7da9fed0474b4cd46055dd92d55c42faf32c19ac Add linux-next specific
files for 20221006
Error/Warning reports:
https://lore.kernel.org/linux-doc/202210070057.npbamyxb-...@intel.com
https
On 10/6/2022 1:09 PM, John Harrison wrote:
On 10/6/2022 10:20, Daniele Ceraolo Spurio wrote:
We're observing sporadic HuC delayed load timeouts in CI, due to mei_pxp
binding completing later than we expected. HuC is still still loaded
still still
when the bind occurs, but in the meantime
On 10/6/2022 13:16, Ceraolo Spurio, Daniele wrote:
On 10/6/2022 1:09 PM, John Harrison wrote:
On 10/6/2022 10:20, Daniele Ceraolo Spurio wrote:
We're observing sporadic HuC delayed load timeouts in CI, due to
mei_pxp
binding completing later than we expected. HuC is still still loaded
still
Hi Alex,
On Thu, 6 Oct 2022 09:56:32 -0400 Alex Deucher wrote:
>
> This looks good to me. Care to add you s-o-b?
>
> On Thu, Oct 6, 2022 at 4:12 AM Stephen Rothwell wrote:
> >
> > This works as well, and (in my opinion) is better:
> >
> > diff --git
On Fri, 7 Oct 2022 at 04:48, Linus Torvalds
wrote:
>
> On Tue, Oct 4, 2022 at 8:42 PM Dave Airlie wrote:
> >
> > Lots of stuff all over, some new AMD IP support and gang
> > submit support [..]
>
> Hmm.
>
> I have now had my main desktop lock up twice after pulling this.
> Nothing in the dmesg
On Thu, Oct 6, 2022 at 12:30 PM Dave Airlie wrote:
>
> netconsole?
I've never been really successful with that in the past, and haven't
used it for decades. I guess I could try if nothing else works.
Linus
On 10/6/2022 10:20, Daniele Ceraolo Spurio wrote:
We're observing sporadic HuC delayed load timeouts in CI, due to mei_pxp
binding completing later than we expected. HuC is still still loaded
still still
when the bind occurs, but in the meantime i915 has started allowing
submission to the VCS
1 - 100 of 129 matches
Mail list logo
