References to struct drm_device.pdev should not be used any longer as
the field will be moved into the struct's legacy section. Add a fix
for the rsp commit.
v2:
* fix an error in the commit description (Michael)
Signed-off-by: Thomas Zimmermann
Reviewed-by: Jani Nikula
Fixes: d57d4a1da
>-Original Message-
>From: Thomas Zimmermann
>Sent: Tuesday, April 27, 2021 1:49 PM
>To: jani.nik...@linux.intel.com; joonas.lahti...@linux.intel.com; Vivi, Rodrigo
>; airl...@linux.ie; dan...@ffwll.ch; Auld, Matthew
>; Ruhl, Michael J
>Cc: intel-...@lists.freedesktop.org; dri-devel@list
On Tue, Apr 27, 2021 at 1:35 PM Simon Ser wrote:
>
> On Tuesday, April 27th, 2021 at 7:31 PM, Lucas Stach
> wrote:
>
> > > Ok. So that would only make the following use cases broken for now:
> > >
> > > - amd render -> external gpu
> > > - amd video encode -> network device
> >
> > FWIW, "only"
On Tuesday, April 27th, 2021 at 8:01 PM, Alex Deucher
wrote:
> It's an upcoming requirement for windows[1], so you are likely to
> start seeing this across all GPU vendors that support windows. I
> think the timing depends on how quickly the legacy hardware support
> sticks around for each vendo
On Tue, 27 Apr 2021 at 22:06, Christian König
wrote:
>
> Correct, we wouldn't have synchronization between device with and without
> user queues any more.
>
> That could only be a problem for A+I Laptops.
Since I think you mentioned you'd only be enabling this on newer
chipsets, won't it be a pr
On Fri, 26 Mar 2021 at 16:29, Thierry Reding
wrote:
> On Fri, Mar 26, 2021 at 02:54:22PM +, Simon Ser wrote:
> > LGTM, thanks!
> >
> > Reviewed-by: Simon Ser
> >
> > Let me know if you need me to push this to drm-misc-next.
>
> I do have commit access for drm-misc-next, but I was thinking th
On 2021-04-26 17:18, Dmitry Baryshkov wrote:
Rework MSM coredump support: add DSI PHY registers, simplify
snapshotting code.
Changes since v1:
- Readd mutex serializing register snapshot calls
- Add DSI PHY register dumping support
Need to mention the dependency here , got missed from the p
Hi Dmitry
On 2021-04-26 17:18, Dmitry Baryshkov wrote:
Instead of allocating snapshotting structure at the driver probe time
and later handling concurrent access, actual state, etc, make
msm_disp_state transient struct. Allocate one when snapshotting happens
and free it after coredump data is re
Supporting interop with any device is always possible. It depends on which
drivers we need to interoperate with and update them. We've already found
the path forward for amdgpu. We just need to find out how many other
drivers need to be updated and evaluate the cost/benefit aspect.
Marek
On Tue,
Hi Dmitry
On 2021-04-26 17:18, Dmitry Baryshkov wrote:
Instead of looping throught the resources each time to get the DSI CTRL
area size, get it at the ioremap time.
Signed-off-by: Dmitry Baryshkov
We will have to call into the individual modules anyway everytime we
take a snapshot as only th
Trying to figure out which e-mail in this mess is the right one to reply to
On Tue, Apr 27, 2021 at 12:31 PM Lucas Stach wrote:
>
> Hi,
>
> Am Dienstag, dem 27.04.2021 um 09:26 -0400 schrieb Marek Olšák:
> > Ok. So that would only make the following use cases broken for now:
> > - amd render
On Tue, 27 Apr 2021 at 22:19, wrote:
>
> Hi Dmitry
>
> On 2021-04-26 17:18, Dmitry Baryshkov wrote:
> > Instead of allocating snapshotting structure at the driver probe time
> > and later handling concurrent access, actual state, etc, make
> > msm_disp_state transient struct. Allocate one when sna
On Tue, 27 Apr 2021 at 22:30, wrote:
>
> Hi Dmitry
>
> On 2021-04-26 17:18, Dmitry Baryshkov wrote:
> > Instead of looping throught the resources each time to get the DSI CTRL
> > area size, get it at the ioremap time.
> >
> > Signed-off-by: Dmitry Baryshkov
> We will have to call into the indivi
With many more non-desktop form factor devices landing in the kernel,
we're starting to run up against some limitations. Notably devices with
display notches, cutouts and rounded corners.
Given that the DRI subsystem already deals with physical display
properties like panel orientation which is
On Tue, Apr 27, 2021 at 1:38 PM Dave Airlie wrote:
>
> On Tue, 27 Apr 2021 at 22:06, Christian König
> wrote:
> >
> > Correct, we wouldn't have synchronization between device with and without
> > user queues any more.
> >
> > That could only be a problem for A+I Laptops.
>
> Since I think you me
On Mon, 26 Apr 2021 17:00:02 -0300
Jason Gunthorpe wrote:
> The mdev bus's core part for managing the lifecycle of devices is mostly
> as one would expect for a driver core bus subsystem.
>
> However instead of having a normal 'struct device_driver' and binding the
> actual mdev drivers through
Jason, both memory-based signalling as well as interrupt-based signalling
to the CPU would be supported by amdgpu. External devices don't need to
support memory-based sync objects. The only limitation is that they can't
convert amdgpu sync objects to dma_fence.
The sad thing is that "external -> a
On 2021-04-27 13:29, Dmitry Baryshkov wrote:
On Tue, 27 Apr 2021 at 22:19, wrote:
Hi Dmitry
On 2021-04-26 17:18, Dmitry Baryshkov wrote:
> Instead of allocating snapshotting structure at the driver probe time
> and later handling concurrent access, actual state, etc, make
> msm_disp_state tra
On 2021-04-27 13:32, Dmitry Baryshkov wrote:
On Tue, 27 Apr 2021 at 22:30, wrote:
Hi Dmitry
On 2021-04-26 17:18, Dmitry Baryshkov wrote:
> Instead of looping throught the resources each time to get the DSI CTRL
> area size, get it at the ioremap time.
>
> Signed-off-by: Dmitry Baryshkov
We w
On 2021-04-26 17:18, Dmitry Baryshkov wrote:
Add DSI PHY registers to the msm state snapshots to be able to check
their contents.
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Abhinav Kumar
---
drivers/gpu/drm/msm/dsi/dsi.c | 1 +
drivers/gpu/drm/msm/dsi/dsi.h | 1 +
drive
On Tue, Apr 27, 2021 at 03:30:42PM -0600, Alex Williamson wrote:
> It'd be really helpful if you could consistently copy at least one
> list, preferably one monitored by patchwork, for an entire series. The
> kvm list is missing patches 06 and 08. I can find the latter hopping
> over to the int
On Mon, 2021-04-26 at 09:42 +0200, Thierry Reding wrote:
> On Fri, Apr 23, 2021 at 02:21:45PM -0400, Lyude Paul wrote:
> > While we're taking a reference of the DDC adapter for a DP AUX channel in
> > tegra_sor_probe() because we're going to be using that adapter with the
> > SOR, now that we've mo
On Tue, 27 Apr 2021 19:20:26 -0300
Jason Gunthorpe wrote:
> On Tue, Apr 27, 2021 at 03:30:42PM -0600, Alex Williamson wrote:
>
> > It'd be really helpful if you could consistently copy at least one
> > list, preferably one monitored by patchwork, for an entire series. The
> > kvm list is missi
On Tue, Apr 27, 2021 at 09:33:56AM +0200, Christian Borntraeger wrote:
> On 26.04.21 19:42, Jason Gunthorpe wrote:
> > On Mon, Apr 26, 2021 at 06:43:14PM +0200, Christian Borntraeger wrote:
> > > On 24.04.21 01:02, Jason Gunthorpe wrote:
> > > > Prologue
> > > >
> > > >
> > > > This is se
I've updated to Fedora 34 on one of my machines, and it causes a lot
of i915 warnings like
drivers/gpu/drm/i915/intel_pm.c: In function ‘ilk_setup_wm_latency’:
drivers/gpu/drm/i915/intel_pm.c:3059:9: note: referencing argument 3
of type ‘const u16 *’ {aka ‘const short unsigned int *’}
driver
Quoting aravi...@codeaurora.org (2021-04-21 11:55:21)
> On 2021-04-21 10:26, khs...@codeaurora.org wrote:
> >>
> >>> +
> >>> mutex_unlock(&dp->event_mutex);
> >>>
> >>> return 0;
> >>> @@ -1496,6 +1502,9 @@ int msm_dp_display_disable(struct msm_dp *dp,
> >>> struct drm_encoder *enco
On Tue, Apr 27, 2021 at 4:43 PM Linus Torvalds
wrote:
>
> I think I will make the argument type to intel_print_wm_latency() be
> just "const u16 wm[]" for now, just to avoid seeing a ton of silly
> warnings.
After fixing the trivial ones, this one remains:
drivers/gpu/drm/i915/display/intel_dp
MTK_MMSYS tristrate support
Chun-Hung Wu (1):
[ALPS05103552] soc: mediatek: MTK_MMSYS tristrate support
drivers/soc/mediatek/Kconfig | 2 +-
drivers/soc/mediatek/mtk-mmsys.c | 7 ++-
2 files changed, 7 insertions(+), 2 deletions(-)
--
1.8.1.1.dirty
__
From: Chun-Hung Wu
MTK_MMSYS driver tristrate support.
Signed-off-by: Chun-Hung Wu
Signed-off-by: Yongqiang Niu
---
drivers/soc/mediatek/Kconfig | 2 +-
drivers/soc/mediatek/mtk-mmsys.c | 7 ++-
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/soc/mediatek/Kconfi
On Mon 26 Apr 19:18 CDT 2021, Dmitry Baryshkov wrote:
[..]
> diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
> index 92fe844b517b..be578fc4e54f 100644
> --- a/drivers/gpu/drm/msm/msm_drv.c
> +++ b/drivers/gpu/drm/msm/msm_drv.c
> @@ -124,7 +124,7 @@ struct clk *msm_clk_get
On Tue, Apr 27, 2021 at 4:32 AM Daniel Vetter wrote:
>
> On Fri, Apr 23, 2021 at 05:31:11PM -0500, Jason Ekstrand wrote:
> > This reverts commit 88be76cdafc7 ("drm/i915: Allow userspace to specify
> > ringsize on construction"). This API was originally added for OpenCL
> > but the compute-runtime
On Tue, Apr 27, 2021 at 4:59 PM Marek Olšák wrote:
>
> Jason, both memory-based signalling as well as interrupt-based signalling to
> the CPU would be supported by amdgpu. External devices don't need to support
> memory-based sync objects. The only limitation is that they can't convert
> amdgpu
drm_dev_register() sets connector->registration_state to
DRM_CONNECTOR_REGISTERED and dev->registered to true. If
drm_connector_set_panel_orientation() is first called after
drm_dev_register(), it will fail several checks and results in following
warning.
Add a function to create panel orientation
Init panel orientation property after connector is initialized. Let the
panel driver decides the orientation value later.
Signed-off-by: Hsin-Yi Wang
---
drivers/gpu/drm/mediatek/mtk_dsi.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
b/drivers/gp
krane, kakadu, and kodama boards have a default panel rotation.
Signed-off-by: Hsin-Yi Wang
---
arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
b/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
inde
On Wed., Apr. 28, 2021, 00:01 Jason Ekstrand, wrote:
> On Tue, Apr 27, 2021 at 4:59 PM Marek Olšák wrote:
> >
> > Jason, both memory-based signalling as well as interrupt-based
> signalling to the CPU would be supported by amdgpu. External devices don't
> need to support memory-based sync object
ttm_bo_swapout returns a non-0 value on success. Don't treat that as an
error in ttm_tt_populate.
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/ttm/ttm_tt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
index 5
SG BOs do not occupy space that is managed by TTM. So do not evict them.
This fixes unexpected evictions of KFD's userptr BOs. KFD only expects
userptr "evictions" in the form of MMU notifiers.
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/ttm/ttm_bo.c | 4
1 file changed, 4 insertions
Hi Dave,
Am 27.04.21 um 21:23 schrieb Marek Olšák:
Supporting interop with any device is always possible. It depends on
which drivers we need to interoperate with and update them. We've
already found the path forward for amdgpu. We just need to find out
how many other drivers need to be update
101 - 139 of 139 matches
Mail list logo
