From: Imre Deak
On MTL TypeC ports the AUX_CH_CTL and AUX_CH_DATA addresses have
changed wrt. previous platforms, adjust the code accordingly.
Signed-off-by: Imre Deak
Signed-off-by: Radhakrishna Sripada
---
drivers/gpu/drm/i915/display/intel_dp_aux.c | 45 -
drivers/gpu/d
Display 14 and future platforms do not directly communicate to Pcode
via mailbox the SAGV bandwidth information. PM Demand registers are
used to communicate display power requirements to the PUnit which would
include GV point and mask value.
Skip programming GV point and mask values through legacy
From: Imre Deak
Add support for display power wells on MTL. The differences from XE_LPD:
- The AUX HW block is moved to the PICA block, where the registers are on
an always-on power well and the functionality needs to be powered on/off
via the AUX_CH_CTL register: [1], [2]
- The DDI IO power
From: Madhumitha Tolakanahalli Pradeep
In Display version 14, Transcoder Chicken Registers are moved from DPRZ to DRPOS
to reduce register signal crossings for Unit Interface Optimization.
This patch modifies the CHICKEN_TRANS macro to add a DISPLAY_VER check for
calculating the correct platfor
>From Meteorlake, Latency Level, SAGV bloack time are read from
LATENCY_SAGV register instead of the GT driver pcode mailbox. DDR type
and QGV information are also to be read from Mem SS registers.
v2:
- Simplify MTL_MEM_SS_INFO_QGV_POINT macro(MattR)
- Nit: Rearrange the bit def's from higher t
From: José Roberto de Souza
The GMD step field do not properly match the current stepping convention
that we use(STEP_A0, STEP_A1, STEP_B0...).
One platform could have { arch = 12, rel = 70, step = 1 } and the
actual stepping is STEP_B0 but without the translation of the step
field would mean ST
From: Matt Roper
Going forward, the hardware teams no longer consider new platforms to
have a "generation" in the way we've defined it for past platforms.
Instead, each IP block (graphics, media, display) will have their own
architecture major.minor versions and stepping ID's which should be read
drm_format_info_* functions don't return bool, and the info variable is a
pointer.
Expecting non-NULL info will cause the test to crash if it is NULL in
checks that follow (which dereference it).
Use appropriate KUNIT_EXPECT/KUNIT_ASSERT variants.
Signed-off-by: Michał Winiarski
---
drivers/gpu/
While we have multiple test cases, most of them check multiple
conditions, calling the function that is tested multiple times with
different arguments (with comments that indicate test case boundary).
This usually means that it can be easily converted into multiple test
cases.
Passing output:
The attempt to read DPCD_REV before any native aux read breaks
majority of DP2 compliance.
The spec. requires DP_SINK_STATUS to be polled for the reset status
DP_INTRA_HOP_AUX_REPLY_INDICATION during the clear training stage.
Polling DP_SINK_STATUS each time gets DPCD_REV read first
that makes no
Hi Michał
Some very minor nits inline, but either way:
Reviewed-by: Maíra Canal
On 8/31/22 18:56, Michał Winiarski wrote:
While we have multiple test cases, most of them check multiple
conditions, calling the function that is tested multiple times with
different arguments (with comments that
On 8/26/2022 7:23 AM, Dmitry Baryshkov wrote:
On 24/08/2022 20:20, Abhinav Kumar wrote:
On 8/24/2022 1:29 AM, Dmitry Baryshkov wrote:
On Wed, 24 Aug 2022 at 04:25, Abhinav Kumar
wrote:
On 6/20/2022 2:30 PM, Dmitry Baryshkov wrote:
The rest of the code expects that master's device drv
To increment a reference the caller already holds. Export
vfio_device_put() to pair with it.
Signed-off-by: Jason Gunthorpe
---
drivers/vfio/vfio_main.c | 3 ++-
include/linux/vfio.h | 6 ++
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/vfio/vfio_main.c b/drivers/
FLR triggered by an emulated config space write should not behave
differently from a FLR triggered by VFIO_DEVICE_RESET, currently the
config space path misses the power management.
Consolidate all the call sites to invoke a single function.
Signed-off-by: Jason Gunthorpe
---
drivers/vfio/pci/v
dma-buf has become a way to safely acquire a handle to non-struct page
memory that can still have lifetime controlled by the exporter. Notably
RDMA can now import dma-buf FDs and build them into MRs which allows for
PCI P2P operations. Extend this to allow vfio-pci to export MMIO memory
from PCI de
Used to increment the refcount of the dma buf's struct file, only if the
refcount is not zero. Useful to allow the struct file's lifetime to
control the lifetime of the dmabuf while still letting the driver to keep
track of created dmabufs.
Signed-off-by: Jason Gunthorpe
---
include/linux/dma-bu
dma-buf has become a way to safely acquire a handle to non-struct page
memory that can still have lifetime controlled by the exporter. Notably
RDMA can now import dma-buf FDs and build them into MRs which allows for
PCI P2P operations. Extend this to allow vfio-pci to export MMIO memory
from PCI de
> From: Alex Williamson
> Sent: Thursday, September 1, 2022 1:15 AM
>
> On Wed, 31 Aug 2022 06:10:51 +
> "Tian, Kevin" wrote:
>
> > > From: Jason Gunthorpe
> > > Sent: Wednesday, August 31, 2022 7:53 AM
> > >
> > > On Tue, Aug 30, 2022 at 04:18:38PM -0600, Alex Williamson wrote:
> > > > On
On Thu, 1 Sep 2022 00:46:51 +
"Tian, Kevin" wrote:
> > From: Alex Williamson
> > Sent: Thursday, September 1, 2022 1:15 AM
> >
> > On Wed, 31 Aug 2022 06:10:51 +
> > "Tian, Kevin" wrote:
> >
> > > > From: Jason Gunthorpe
> > > > Sent: Wednesday, August 31, 2022 7:53 AM
> > > >
> >
On Wed, Aug 31, 2022 at 08:38:48AM +0100, Tvrtko Ursulin wrote:
On 27/08/2022 20:43, Andi Shyti wrote:
From: Niranjana Vishwanathapura
Implement new execbuf3 ioctl (I915_GEM_EXECBUFFER3) which only
works in vm_bind mode. The vm_bind mode only works with
this new execbuf3 ioctl.
The new execb
On Tue, Aug 30, 2022 at 07:19:17PM +0100, Matthew Auld wrote:
On 27/08/2022 20:43, Andi Shyti wrote:
From: Niranjana Vishwanathapura
Implement the bind and unbind of an object at the specified GPU virtual
addresses.
Signed-off-by: Niranjana Vishwanathapura
Signed-off-by: Prathap Kumar Valsan
On Sun, 28 Aug 2022 at 05:45, Andi Shyti wrote:
>
> From: Niranjana Vishwanathapura
>
> Implement the bind and unbind of an object at the specified GPU virtual
> addresses.
>
> Signed-off-by: Niranjana Vishwanathapura
> Signed-off-by: Prathap Kumar Valsan
> Signed-off-by: Ramalingam C
> Signed
Am 31.08.22 um 17:37 schrieb Dmitry Osipenko:
Prepare DRM prime core to the common dynamic dma-buf locking convention
by starting to use the unlocked versions of dma-buf API functions.
Signed-off-by: Dmitry Osipenko
Reviewed-by: Christian König
---
drivers/gpu/drm/drm_prime.c | 6 +++---
Am 31.08.22 um 17:37 schrieb Dmitry Osipenko:
Prepare Armada driver to the common dynamic dma-buf locking convention
by starting to use the unlocked versions of dma-buf API functions.
Signed-off-by: Dmitry Osipenko
Acked-by: Christian König
---
drivers/gpu/drm/armada/armada_gem.c | 8 +++
Am 31.08.22 um 17:37 schrieb Dmitry Osipenko:
Prepare i915 driver to the common dynamic dma-buf locking convention
by starting to use the unlocked versions of dma-buf API functions
and handling cases where importer now holds the reservation lock.
Signed-off-by: Dmitry Osipenko
Acked-by: Chris
Am 31.08.22 um 17:37 schrieb Dmitry Osipenko:
Prepare OMAP DRM driver to the common dynamic dma-buf locking convention
by starting to use the unlocked versions of dma-buf API functions.
Signed-off-by: Dmitry Osipenko
Acked-by: Christian König
---
drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c
Am 31.08.22 um 17:37 schrieb Dmitry Osipenko:
Prepare Tegra DRM driver to the common dynamic dma-buf locking convention
by starting to use the unlocked versions of dma-buf API functions.
Signed-off-by: Dmitry Osipenko
Acked-by: Christian König
---
drivers/gpu/drm/tegra/gem.c | 17 +++
Am 31.08.22 um 17:37 schrieb Dmitry Osipenko:
Prepare Etnaviv driver to the common dynamic dma-buf locking convention
by starting to use the unlocked versions of dma-buf API functions.
Signed-off-by: Dmitry Osipenko
Interesting, where is the matching vmap()?
Anyway, this patch is Acked-by: C
Am 31.08.22 um 17:37 schrieb Dmitry Osipenko:
Prepare InfiniBand drivers to the common dynamic dma-buf locking
convention by starting to use the unlocked versions of dma-buf API
functions.
Signed-off-by: Dmitry Osipenko
Acked-by: Christian König
---
drivers/infiniband/core/umem_dmabuf.c
Am 31.08.22 um 17:37 schrieb Dmitry Osipenko:
Prepare fastrpc to the common dynamic dma-buf locking convention by
starting to use the unlocked versions of dma-buf API functions.
Signed-off-by: Dmitry Osipenko
Acked-by: Christian König
---
drivers/misc/fastrpc.c | 6 +++---
1 file change
101 - 130 of 130 matches
Mail list logo
