On Wed, Jul 28, 2021 at 11:37:30PM +0200, David Sterba wrote:
> On Wed, Jul 28, 2021 at 02:37:20PM -0700, Bart Van Assche wrote:
> > On 7/28/21 2:14 AM, Dan Carpenter wrote:
> > > On Wed, Jul 28, 2021 at 10:59:22AM +0200, David Sterba wrote:
> > >>> drivers/media/platform/omap3isp/ispstat.c | 5
Hi Chun-Kuang,
Thanks for your review.
On Wed, 2021-07-28 at 07:39 +0800, Chun-Kuang Hu wrote:
> Hi, Nancy:
>
> Nancy.Lin 於 2021年7月22日 週四 下午5:46寫道：
> >
> > Add ETHDR module files:
> > ETHDR is designed for HDR video and graphics conversion in the
> > external
> > display path. It handles
The user can open multiple device FDs if it likes, however these open()
functions call vfio_register_notifier() on some device global
state. Calling vfio_register_notifier() twice in will trigger a WARN_ON
from notifier_chain_register() and the first close will wrongly delete the
notifier and
Hi Georgi,
On 2021-07-28 19:30, Georgi Djakov wrote:
On Mon, Jan 11, 2021 at 07:45:02PM +0530, Sai Prakash Ranjan wrote:
commit ecd7274fb4cd ("iommu: Remove unused IOMMU_SYS_CACHE_ONLY flag")
removed unused IOMMU_SYS_CACHE_ONLY prot flag and along with it went
the memory type setting required
Kees,
> For example, change it to:
>
> + BUILD_BUG_ON(sizeof(evt_struct->iu.srp) != SRP_MAX_IU_LEN);
> + memset(_struct->iu.srp, 0x00, sizeof(evt_struct->iu.srp));
> srp_cmd = _struct->iu.srp.cmd;
> - memset(srp_cmd, 0x00, SRP_MAX_IU_LEN);
> For the moment, I'll leave the
Hi Dave, Daniel,
Fixes for 5.14.
The following changes since commit ff1176468d368232b684f75e82563369208bc371:
Linux 5.14-rc3 (2021-07-25 15:35:14 -0700)
are available in the Git repository at:
https://gitlab.freedesktop.org/agd5f/linux.git
tags/amd-drm-fixes-5.14-2021-07-28
for you to
On Wed, Jul 28, 2021 at 7:18 PM Caleb Connolly
wrote:
>
>
>
> On 29/07/2021 02:02, Rob Clark wrote:
> > Jordan, any idea if more frequent frequency changes would for some
> > reason make a630 grumpy? I was expecting it should be somewhat
> > similar to a618 (same GMU fw, etc). The main result
On July 28, 2021 10:57:23 Matthew Auld wrote:
No need to hand roll the set_placements stuff, now that that we have a
helper for this. Also no need to handle the -ENODEV case here, since
NULL mr implies missing device support, where the for_each_memory_region
helper will always skip over such
From: "Huang, Sean Z"
During the power event S3+ sleep/resume, hardware will lose all the
encryption keys for every hardware session, even though the
session state might still be marked as alive after resume. Therefore,
we should consider the session as dead on suspend and invalidate all the
Note that discrete cards can support PXP as well, but we haven't tested
on those yet so keeping it disabled for now.
Signed-off-by: Daniele Ceraolo Spurio
Reviewed-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/i915_pci.c | 2 ++
1 file changed, 2 insertions(+)
diff --git
From: Anshuman Gupta
When protected sufaces has flipped and pxp session is disabled,
display black pixels by using plane color CTM correction.
v2:
- Display black pixels in async flip too.
v3:
- Removed the black pixels logic for async flip. [Ville]
- Used plane state to force black pixels.
From: Anshuman Gupta
Add support to enable/disable PLANE_SURF Decryption Request bit.
It requires only to enable plane decryption support when following
condition met.
1. PXP session is enabled.
2. Buffer object is protected.
v2:
- Used gen fb obj user_flags instead gem_object_metadata.
From: "Huang, Sean Z"
The HW will generate a teardown interrupt when session termination is
required, which requires i915 to submit a terminating batch. Once the HW
is done with the termination it will generate another interrupt, at
which point it is safe to re-create the session.
Since the
This api allow user mode to create protected buffers and to mark
contexts as making use of such objects. Only when using contexts
marked in such a way is the execution guaranteed to work as expected.
Contexts can only be marked as using protected content at creation time
(i.e. the parameter is
From: "Huang, Sean Z"
Teardown is triggered when the display topology changes and no
long meets the secure playback requirement, and hardware trashes
all the encryption keys for display. Additionally, we want to emit a
teardown operation to make sure we're clean on boot and resume
v2: emit in
Now that we can handle destruction and re-creation of the arb session,
we can postpone the start of the session to the first submission that
requires it, to avoid keeping it running with no user.
Signed-off-by: Daniele Ceraolo Spurio
Reviewed-by: Rodrigo Vivi
---
From: "Huang, Sean Z"
Create the arbitrary session, with the fixed session id 0xf, after
system boot, for the case that application allocates the protected
buffer without establishing any protection session. Because the
hardware requires at least one alive session for protected buffer
creation.
The setting is required by hardware to allow us doing further protection
operation such as sending commands to GPU or TEE. The register needs to
be re-programmed on resume, so for simplicitly we bundle the programming
with the component binding, which is automatically called on resume.
Further HW
From: "Huang, Sean Z"
Implement the funcs to create the TEE channel, so kernel can
send the TEE commands directly to TEE for creating the arbitrary
(default) session.
v2: fix locking, don't pollute dev_priv (Chris)
v3: wait for mei PXP component to be bound.
v4: drop the wait, as the
The context is required to send the session termination commands to the
VCS, which will be implemented in a follow-up patch. We can also use the
presence of the context as a check of pxp initialization completion.
v2: use perma-pinned context (Chris)
v3: rename pinned_context functions (Chris)
Ahead of the PXP implementation, define the relevant define flag and
kconfig option.
v2: flip kconfig default to N. Some machines have IFWIs that do not
support PXP, so we need it to be an opt-in until we add support to query
the caps from the mei device.
Signed-off-by: Daniele Ceraolo Spurio
This will be used for communication between the i915 driver and the mei
one. Defining it in a stand-alone patch to avoid circualr dependedencies
between the patches modifying the 2 drivers.
Split out from an original patch from Huang, Sean Z
v2: rename the component struct (Rodrigo)
PXP (Protected Xe Path) is an i915 component, available on
GEN12+, that helps to establish the hardware protected session
and manage the status of the alive software session, as well
as its life cycle.
Very minimal changes from v5:
- Update mei_pxp match code to look the same as mei_hdcp (no
From: Vitaly Lubart
Export PAVP client to work with i915 driver,
for binding it uses kernel component framework.
v2:drop debug prints, refactor match code to match mei_hdcp (Tomas)
Signed-off-by: Vitaly Lubart
Signed-off-by: Tomas Winkler
Signed-off-by: Daniele Ceraolo Spurio
Reviewed-by:
On 7/28/21 2:01 PM, Kees Cook wrote:
> On Wed, Jul 28, 2021 at 07:55:53AM +0200, Greg Kroah-Hartman wrote:
>>> struct ethhdr {
>>> - unsigned char h_dest[ETH_ALEN]; /* destination eth addr */
>>> - unsigned char h_source[ETH_ALEN]; /* source ether addr*/
>>> + union {
>>>
Jordan, any idea if more frequent frequency changes would for some
reason make a630 grumpy? I was expecting it should be somewhat
similar to a618 (same GMU fw, etc). The main result of that patch
should be clamping to min freq when gpu goes idle, and the toggling
back to devfreq provided freq on
Keep track of all the vfio_devices that have been added to the device set
and use this list in vfio_pci_try_bus_reset() instead of trying to work
backwards from the pci_device.
The dev_set->lock directly prevents devices from joining/leaving the set,
which further implies the pci_device cannot
Nothing uses this anymore, delete it.
Signed-off-by: Yishai Hadas
Reviewed-by: Christoph Hellwig
Signed-off-by: Jason Gunthorpe
---
drivers/vfio/mdev/vfio_mdev.c | 22 --
drivers/vfio/vfio.c | 14 +-
include/linux/mdev.h | 7 ---
The patch to move the get/put to core and the patch to convert the samples
to use vfio_device crossed in a way that this was missed. When both
patches are together the samples do not need their own get/put.
Fixes: 437e41368c01 ("vfio/mdpy: Convert to use vfio_register_group_dev()")
Fixes:
From: Max Gurtovoy
This pairs with vfio_init_group_dev() and allows undoing any state that is
stored in the vfio_device unrelated to registration. Add appropriately
placed calls to all the drivers.
The following patch will use this to add pre-registration state for the
device set.
The user can open multiple device FDs if it likes, however the open
function calls vfio_register_notifier() on device global state. Calling
vfio_register_notifier() twice will trigger a WARN_ON from
notifier_chain_register() and the first close will wrongly delete the
notifier and more.
Since
FSL uses the internal reflck to implement the open_device() functionality,
conversion to the core code is straightforward.
The decision on which set to be part of is trivially based on the
is_fsl_mc_bus_dprc() and we use a 'struct device *' pointer as the set_id.
The dev_set lock is protecting
Like vfio_pci_try_bus_reset() this code wants to reset all of the devices
in the "reset group" which is the same membership as the device set.
Instead of trying to reconstruct the device set from the PCI list go
directly from the device set's device list to execute the reset.
The same basic
The core code no longer requires these ops to be defined, so delete these
empty functions and leave the op as NULL. mtty's functions only log a
pointless message, delete that entirely.
Signed-off-by: Yishai Hadas
Reviewed-by: Cornelia Huck
Reviewed-by: Christoph Hellwig
Signed-off-by: Jason
mbochs_close() iterates over global device state and frees it. Currently
this is done every time a device FD is closed, but if multiple device FDs
are open this could corrupt other still active FDs.
Change this to use close_device() so it only runs on the last close.
Reviewed-by: Cornelia Huck
Currently the driver ops have an open/release pair that is called once
each time a device FD is opened or closed. Add an additional set of
open/close_device() ops which are called when the device FD is opened for
the first time and closed for the last time.
An analysis shows that all of the
Convert mbochs to use an atomic scheme for this like mtty was changed
into. The atomic fixes various race conditions with probing. Add the
missing error unwind. Also add the missing kfree of mdev_state->pages.
Fixes: 681c1615f891 ("vfio/mbochs: Convert to use vfio_register_group_dev()")
From: Yishai Hadas
PCI wants to have the usual open/close_device() logic with the slight
twist that the open/close_device() must be done under a singelton lock
shared by all of the vfio_devices that are in the PCI "reset group".
The reset group, and thus the device set, is determined by what
Platform simply wants to run some code when the device is first
opened/last closed. Use the core framework and locking for this. Aside
from removing a bit of code this narrows the locking scope from a global
lock.
Signed-off-by: Jason Gunthorpe
Signed-off-by: Yishai Hadas
Reviewed-by: Cornelia
This is in support of Max's series to split vfio-pci. For that to work the
reflck concept embedded in vfio-pci needs to be sharable across all of the
new VFIO PCI drivers which motivated re-examining how this is
implemented.
Another significant issue is how the VFIO PCI core includes code like:
If an engine associated with a context does not have a heartbeat, ban it
immediately. This is needed for GuC submission as a idle pulse doesn't
kick the context off the hardware where it then can check for a
heartbeat and ban the context.
This patch also updates intel_engine_has_heartbeat to be a
Should fix below failures with GuC submission for the following tests:
gem_exec_balancer --r noheartbeat
gem_ctx_persistence --r heartbeat-close
Not going to fix:
gem_ctx_persistence --r heartbeat-many
gem_ctx_persistence --r heartbeat-stop
As the above tests change the heartbeat value to 0
https://bugzilla.kernel.org/show_bug.cgi?id=213373
Erhard F. (erhar...@mailbox.org) changed:
What|Removed |Added
Attachment #297249|0 |1
is obsolete|
On 7/22/2021 12:26 PM, Jason Gunthorpe wrote:
On Thu, Jul 22, 2021 at 11:59:17AM -0500, Sierra Guiza, Alejandro (Alex) wrote:
On 7/22/2021 7:23 AM, Jason Gunthorpe wrote:
On Sat, Jul 17, 2021 at 02:21:32PM -0500, Alex Sierra wrote:
In order to configure device generic in test_hmm, two
On Wed, Jul 28, 2021 at 10:35:56AM +0300, Dan Carpenter wrote:
> On Tue, Jul 27, 2021 at 01:57:53PM -0700, Kees Cook wrote:
> > [...]
> > - /**
> > -* @it_present: (first) present word
> > -*/
> > - __le32 it_present;
> > + union {
> > + /**
> > +* @it_present:
Hi Sam,
> -Original Message-
> From: Sam Ravnborg
> Sent: Wednesday, July 28, 2021 12:27 AM
> To: Chrisanthus, Anitha
> Cc: dri-devel@lists.freedesktop.org; Dea, Edmund J
> ; Dan Carpenter
> Subject: Re: [PATCH 12/14] drm/kmb: Fix possible oops in error handling
>
> Hi Anitha,
>
> On
Hi Sam,
On 7/28/21 12:08 PM, Sam Ravnborg wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> Hi Dan,
>
Just to be sure...
Can you confirm that vbltest is working OK *before* this patch?
>>>
>>> Yes, can you please verify that
On Wed, Jul 28, 2021 at 10:35:56AM +0300, Dan Carpenter wrote:
> On Tue, Jul 27, 2021 at 01:57:53PM -0700, Kees Cook wrote:
> > In preparation for FORTIFY_SOURCE performing compile-time and run-time
> > field bounds checking for memcpy(), memmove(), and memset(), avoid
> > intentionally writing
Hi Sam,
Thanks for the review.
> -Original Message-
> From: Sam Ravnborg
> Sent: Wednesday, July 28, 2021 12:31 AM
> To: Chrisanthus, Anitha
> Cc: dri-devel@lists.freedesktop.org; Dea, Edmund J
>
> Subject: Re: [PATCH 14/14] drm/kmb: Enable support for fbcon (framebuffer
> console)
>
Hi Sam,
Thanks for you review.
> -Original Message-
> From: Sam Ravnborg
> Sent: Wednesday, July 28, 2021 12:16 AM
> To: Chrisanthus, Anitha
> Cc: dri-devel@lists.freedesktop.org; Dea, Edmund J
>
> Subject: Re: [PATCH 04/14] drm/kmb : W/A for 256B cache alignment for video
>
> Hi
Please ignore this patch. Will combine this with 256B w/a patch.
> -Original Message-
> From: Chrisanthus, Anitha
> Sent: Tuesday, July 27, 2021 5:31 PM
> To: dri-devel@lists.freedesktop.org; Chrisanthus, Anitha
> ; Dea, Edmund J
> Subject: [PATCH 09/14] drm/kmb : W/A for planar formats
Hi Thomas,
On 7/28/21 11:17 AM, Thomas Zimmermann wrote:
> Hi
>
> Am 28.07.21 um 20:11 schrieb Sam Ravnborg:
>> Hi Dan,
>>
>> thanks for the quick feedback!
>>
>> On Wed, Jul 28, 2021 at 05:50:34PM +, dan.sned...@microchip.com
>> wrote:
>>> On 7/28/21 8:44 AM, Sam Ravnborg wrote:
VDDA is not present and the specified load value is wrong. Fix it.
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/dsi/dsi_cfg.c | 1 -
drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c | 2 +-
2 files changed, 1 insertion(+), 2 deletions(-)
diff --git
On 7/28/21 11:11 AM, Sam Ravnborg wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> Hi Dan,
>
> thanks for the quick feedback!
>
> On Wed, Jul 28, 2021 at 05:50:34PM +, dan.sned...@microchip.com wrote:
>> On 7/28/21 8:44 AM, Sam
CNL is the only platform with GRAPHICS_VER == 10. With its removal we
don't need to handle that version anymore.
Also we can now reduce the max number of slices: the call to
intel_sseu_set_info() with the highest number of slices comes from SKL
and BDW with 3 slices. Recent platforms actually
Replace all remaining handling of GRAPHICS_VER {==,>=} 10 with
{==,>=} 11. With the removal of CNL, there is no platform with graphics
version equals 10.
Signed-off-by: Lucas De Marchi
Reviewed-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/gt/debugfs_gt_pm.c | 10 ++---
This the part of https://patchwork.freedesktop.org/series/93056/
that should go through drm-intel-gt-next branch.
Lucas De Marchi (4):
drm/i915/gt: remove explicit CNL handling from intel_mocs.c
drm/i915/gt: remove explicit CNL handling from intel_sseu.c
drm/i915/gt: rename CNL references
Only one reference to CNL that is not needed, but code is the same for
GEN9_BC, so leave the code around and just remove the special
case for CNL.
Signed-off-by: Lucas De Marchi
Reviewed-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/gt/intel_mocs.c | 2 +-
1 file changed, 1 insertion(+), 1
With the removal of CNL, let's consider ICL as the first platform using
that index.
Signed-off-by: Lucas De Marchi
Reviewed-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/gt/intel_engine.h | 2 +-
drivers/gpu/drm/i915/i915_drv.h| 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
On Wed, Jul 28, 2021 at 12:54:18PM +0200, Rasmus Villemoes wrote:
> On 27/07/2021 22.57, Kees Cook wrote:
>
> > In order to have a regular programmatic way to describe a struct
> > region that can be used for references and sizing, can be examined for
> > bounds checking, avoids forcing the use
On 7/28/21 8:44 AM, Sam Ravnborg wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> Hi Dan,
>
> On Wed, Jul 28, 2021 at 03:11:08PM +, dan.sned...@microchip.com wrote:
>> On 7/28/21 7:00 AM, Sam Ravnborg wrote:
>>> [You don't often get
On Wed, Jul 28, 2021 at 11:42:15AM +0200, David Sterba wrote:
> On Tue, Jul 27, 2021 at 01:58:38PM -0700, Kees Cook wrote:
> > In preparation for FORTIFY_SOURCE performing compile-time and run-time
> > field bounds checking for memset(), avoid intentionally writing across
> > neighboring fields.
>
On Wed, Jul 28, 2021 at 11:23:23AM +0200, David Sterba wrote:
> On Wed, Jul 28, 2021 at 10:35:56AM +0300, Dan Carpenter wrote:
> > @@ -372,7 +372,7 @@ ieee80211_add_rx_radiotap_header(struct ieee80211_local
> > *local,
> > ieee80211_calculate_rx_timestamp(local, status,
> >
On 7/27/21 1:58 PM, Kees Cook wrote:
In preparation for FORTIFY_SOURCE performing compile-time and run-time
field bounds checking for memset(), avoid intentionally writing across
neighboring fields.
Add a struct_group() for the algs so that memset() can correctly reason
about the size.
On Wed, Jul 28, 2021 at 02:37:20PM -0700, Bart Van Assche wrote:
> On 7/28/21 2:14 AM, Dan Carpenter wrote:
> > On Wed, Jul 28, 2021 at 10:59:22AM +0200, David Sterba wrote:
> >>> drivers/media/platform/omap3isp/ispstat.c | 5 +--
> >>> include/uapi/linux/omap3isp.h | 44
On 7/28/21 2:14 AM, Dan Carpenter wrote:
On Wed, Jul 28, 2021 at 10:59:22AM +0200, David Sterba wrote:
drivers/media/platform/omap3isp/ispstat.c | 5 +--
include/uapi/linux/omap3isp.h | 44 +--
2 files changed, 36 insertions(+), 13 deletions(-)
diff --git
Currently at dp_pm_resume() is_connected state is decided base on hpd connection
status only. This will put is_connected in wrongly "true" state at the scenario
that dongle attached to DUT but without hmdi cable connecting to it. Fix this
problem by adding read sink count from dongle and decided
On Tue, Jul 27, 2021 at 10:03 AM Sean Paul wrote:
>
> On Thu, Jul 22, 2021 at 11:20 AM Sean Paul wrote:
> >
>
> Reply-all fail. Adding everyone else back to my response.
>
> > On Tue, Jul 20, 2021 at 03:29:34PM +0200, Daniel Vetter wrote:
> > > On Wed, Jul 14, 2021 at 11:51:36AM -0600, Jim
On Wed, Jul 28, 2021 at 10:35:56AM +0300, Dan Carpenter wrote:
> On Tue, Jul 27, 2021 at 01:57:53PM -0700, Kees Cook wrote:
> > In preparation for FORTIFY_SOURCE performing compile-time and run-time
> > field bounds checking for memcpy(), memmove(), and memset(), avoid
> > intentionally writing
Tests that exercise the SLPC get/set frequency interfaces.
Clamp_max will set max frequency to multiple levels and check
that SLPC requests frequency lower than or equal to it.
Clamp_min will set min frequency to different levels and check
if SLPC requests are higher or equal to those levels.
Update the get/set min/max freq hooks to work for
SLPC case as well. Consolidate helpers for requested/min/max
frequency get/set to intel_rps where the proper action can
be taken depending on whether SLPC is enabled.
v2: Add wrappers for getting rp0/1/n frequencies, update
softlimits in set
This feature hands over the control of HW RC6 to the GuC.
GuC decides when to put HW into RC6 based on it's internal
busyness algorithms.
GuCRC needs GuC submission to be enabled, and only
supported on Gen12+ for now.
When GuCRC is enabled, do not set HW RC6. Use a H2G message
to tell GuC to
Cache rp0, rp1 and rpn platform limits into SLPC structure
for range checking while setting min/max frequencies.
Also add "soft" limits which keep track of frequency changes
made from userland. These are initially set to platform min
and max.
v2: Address review comments (Michal W)
v3: Formatting
This interrupt is enabled during RPS initialization, and
now needs to be done by SLPC code. It allows ARAT timer
expiry interrupts to get forwarded to GuC.
v2: Fix comment (Matthew Brost)
Reviewed-by: Matthew Brost
Signed-off-by: Vinay Belgaumkar
---
The assumption when it was added was that GT would not be
holding any gt_pm references. However, uc_init is called
from gt_init_hw, which holds a forcewake ref. If SLPC
enable fails, we will still be holding this ref, which will
result in the BUG_ON.
Reviewed-by: Matthew Brost
Signed-off-by:
This prints out relevant SLPC info from the SLPC shared structure.
We will send a H2G message which forces SLPC to update the
shared data structure with latest information before reading it.
v2: Address review comments (Michal W)
v3: Remove unnecessary tasks from slpc_info (Michal W)
v4: Rename
Add param set h2g helpers to set the min and max frequencies
for use by SLPC.
v2: Address review comments (Michal W)
v3: Check for positive error code (Michal W)
v4: Print generic error in set_param (Michal W)
Signed-off-by: Sundaresan Sujaritha
Signed-off-by: Vinay Belgaumkar
---
Add helpers to read the min/max frequency being used
by SLPC. This is done by send a H2G command which forces
SLPC to update the shared data struct which can then be
read. These helpers will be used in a sysfs patch later
on.
v2: Address review comments (Michal W)
v3: Return err in case of query
Add methods for interacting with GuC for enabling SLPC. Enable
SLPC after GuC submission has been established. GuC load will
fail if SLPC cannot be successfully initialized. Add various
helper methods to set/unset the parameters for SLPC. They can
be set using H2G calls or directly setting bits in
Allocate data structures for SLPC and functions for
initializing on host side.
v2: Address review comments (Michal W)
v3: Remove unnecessary header includes (Michal W)
v4: Rebase
Reviewed-by: Michal Wajdeczko
Signed-off-by: Vinay Belgaumkar
Signed-off-by: Sundaresan Sujaritha
---
Also ensure uc_init is called before we initialize RPS so that we
can check for SLPC support. We do not need to enable up/down
interrupts when SLPC is enabled. However, we still need the ARAT
interrupt, which will be enabled separately later.
Signed-off-by: Vinay Belgaumkar
Signed-off-by:
This series enables Single Loop Power Control (SLPC) feature in GuC.
GuC implements various power management algorithms as part of it's
operation. These need to be specifically enabled by KMD. They replace
the legacy host based management of these features.
With this series, we will enable two PM
Add constants and params that are needed to configure SLPC.
v2: Add a new abi header for SLPC. Replace bitfields with
genmasks. Address other comments from Michal W.
v3: Add slpc H2G format in abi, other review commments (Michal W)
v4: Update status bits according to latest spec
Signed-off-by:
Add macros to check for SLPC support. This feature is currently supported
for Gen12+ and enabled whenever GuC submission is enabled/selected.
Include templates for SLPC init/fini and enable.
v2: Move SLPC helper functions to intel_guc_slpc.c/.h. Define basic
template for SLPC structure in
On Wed, Jul 28, 2021 at 07:55:53AM +0200, Greg Kroah-Hartman wrote:
> > struct ethhdr {
> > - unsigned char h_dest[ETH_ALEN]; /* destination eth addr */
> > - unsigned char h_source[ETH_ALEN]; /* source ether addr*/
> > + union {
> > + struct {
> > +
Hi Dave & Daniel,
An early pull for v5.15 (there'll be more coming in a week or two),
consisting of the drm/scheduler conversion and a couple other small
series that one was based one. Mostly sending this now because IIUC
danvet wanted it in drm-next so he could rebase on it. (Daniel, if
you
Hi Dan,
> >
> > I think I got it - we need to set irq_enabled to true.
> > The documentation says so:
> > "
> > * @irq_enabled:
> > *
> > * Indicates that interrupt handling is enabled, specifically
> > vblank
> > * handling. Drivers which don't use
On 28/07/2021, Kees Cook wrote:
> In preparation for FORTIFY_SOURCE performing compile-time and run-time
> field array bounds checking for memcpy(), memmove(), and memset(),
> avoid intentionally writing across neighboring fields.
>
> Use struct_group() in struct libipw_qos_information_element
]
[If your patch is applied to the wrong git tree, kindly drop us 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/Jackie-Liu/drm-rcar-du-crtc-force-depends-on-cmm/20210728
On 7/28/21 7:00 AM, Sam Ravnborg wrote:
> [You don't often get email from s...@ravnborg.org. Learn why this is
> important at http://aka.ms/LearnAboutSenderIdentification.]
>
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> Hi Dan,
>
> I hope
Hi Dan,
> >>
> >> Just to be sure...
> >> Can you confirm that vbltest is working OK *before* this patch?
> >
> > Yes, can you please verify that it regressed. If so, this would mean
> > that the driver misses vblank interrupts with the patch applied.
>
> Yes, unfortunately the vbltest works
https://bugzilla.kernel.org/show_bug.cgi?id=205089
Alois Nespor (i...@aloisnespor.info) changed:
What|Removed |Added
CC|
Disable bonding on gen12+ platforms aside from ones already supported by
the i915 - TGL, RKL, and ADL-S.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
On Tue, Jul 27, 2021 at 09:39:39PM -0400, Martin K. Petersen wrote:
>
> Kees,
>
> > In preparation for FORTIFY_SOURCE performing compile-time and run-time
> > field bounds checking for memset(), avoid intentionally writing across
> > neighboring fields.
> >
> > Instead of writing beyond the end
Hi
Am 28.07.21 um 20:11 schrieb Sam Ravnborg:
Hi Dan,
thanks for the quick feedback!
On Wed, Jul 28, 2021 at 05:50:34PM +, dan.sned...@microchip.com wrote:
On 7/28/21 8:44 AM, Sam Ravnborg wrote:
EXTERNAL EMAIL: Do not click links or open attachments unless you know the
content is safe
Hi Sam
Am 28.07.21 um 15:31 schrieb Sam Ravnborg:
Hi Thomas,
On Tue, Jul 27, 2021 at 08:27:09PM +0200, Thomas Zimmermann wrote:
Drop the DRM IRQ midlayer in favor of Linux IRQ interfaces. DRM's
IRQ helpers are mostly useful for UMS drivers. Modern KMS drivers
don't benefit from using it.
DRM
Hi Dan,
thanks for the quick feedback!
On Wed, Jul 28, 2021 at 05:50:34PM +, dan.sned...@microchip.com wrote:
> On 7/28/21 8:44 AM, Sam Ravnborg wrote:
> > EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> > content is safe
> >
> > Hi Dan,
> >
> > On Wed, Jul
On Wed, Jul 28, 2021 at 01:38:58PM +, Wang, Zhi A wrote:
> I guess those APIs you were talking about are KVM-only. For other
> hypervisors, e.g. Xen, ARCN cannot use the APIs you mentioned. Not
> sure if you have already noticed that VFIO is KVM-only right now.
There is very little hard
On Wed, Jul 28, 2021 at 10:23 AM Christian König
wrote:
>
>
>
> Am 28.07.21 um 17:15 schrieb Rob Clark:
> > On Wed, Jul 28, 2021 at 4:37 AM Christian König
> > wrote:
> >> Am 28.07.21 um 09:03 schrieb Christian König:
> >>> Am 27.07.21 um 16:25 schrieb Rob Clark:
> On Tue, Jul 27, 2021 at
Am 28.07.21 um 17:15 schrieb Rob Clark:
On Wed, Jul 28, 2021 at 4:37 AM Christian König
wrote:
Am 28.07.21 um 09:03 schrieb Christian König:
Am 27.07.21 um 16:25 schrieb Rob Clark:
On Tue, Jul 27, 2021 at 12:11 AM Christian König
wrote:
Am 27.07.21 um 01:38 schrieb Rob Clark:
From: Rob
1 - 100 of 243 matches
Mail list logo
