Re: [PATCH 3/5] drm/virtio: track whether or not a context has been initiated
On Fri, Feb 14, 2020 at 6:29 PM Gurchetan Singh
wrote:
>
> On Fri, Feb 14, 2020 at 11:27 AM Chia-I Wu wrote:
> >
> > On Thu, Feb 13, 2020 at 3:18 PM Gurchetan Singh
> > wrote:
> > >
> > > Use an atomic variable to track whether a context has been
> > > initiated.
> > >
> > > v2: Fix possible race (@olv)
> > >
> > > Signed-off-by: Gurchetan Singh
> > > ---
> > > drivers/gpu/drm/virtio/virtgpu_drv.h | 1 +
> > > drivers/gpu/drm/virtio/virtgpu_ioctl.c | 3 +++
> > > drivers/gpu/drm/virtio/virtgpu_kms.c | 1 +
> > > 3 files changed, 5 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h
> > > b/drivers/gpu/drm/virtio/virtgpu_drv.h
> > > index 72c1d9b59dfe..ca505984f8ab 100644
> > > --- a/drivers/gpu/drm/virtio/virtgpu_drv.h
> > > +++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
> > > @@ -209,6 +209,7 @@ struct virtio_gpu_device {
> > >
> > > struct virtio_gpu_fpriv {
> > > uint32_t ctx_id;
> > > + atomic_t context_initiated;
> > > };
> > >
> > > /* virtio_ioctl.c */
> > > diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
> > > b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
> > > index 896c3f419a6d..a98884462944 100644
> > > --- a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
> > > +++ b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
> > > @@ -44,6 +44,9 @@ void virtio_gpu_create_context(struct drm_device *dev,
> > > if (!vgdev->has_virgl_3d)
> > > return;
> > >
> > > + if (!atomic_add_unless(>context_initiated, 1, 1))
> > > + return;
> > > +
> > How does this work? When thread A and B enter this function at the
> > same time, and thread B returns early, it is possible that thread B
> > queues other commands before thread A has the chance to queue
> > virtio_gpu_cmd_context_create.
>
> Good catch, I'll add a spinlock in v3.
virtio_gpu_cmd_context_create can sleep. You will need a mutex (or
figure out another way to do the lazy initialization).
>
> >
> > > get_task_comm(dbgname, current);
> > > virtio_gpu_cmd_context_create(vgdev, vfpriv->ctx_id,
> > > strlen(dbgname), dbgname);
> > > diff --git a/drivers/gpu/drm/virtio/virtgpu_kms.c
> > > b/drivers/gpu/drm/virtio/virtgpu_kms.c
> > > index 282558576527..25248bad3fc4 100644
> > > --- a/drivers/gpu/drm/virtio/virtgpu_kms.c
> > > +++ b/drivers/gpu/drm/virtio/virtgpu_kms.c
> > > @@ -263,6 +263,7 @@ int virtio_gpu_driver_open(struct drm_device *dev,
> > > struct drm_file *file)
> > > }
> > >
> > > vfpriv->ctx_id = handle + 1;
> > > + atomic_set(>context_initiated, 0);
> > > file->driver_priv = vfpriv;
> > > virtio_gpu_create_context(dev, file);
> > > return 0;
> > > --
> > > 2.25.0.265.gbab2e86ba0-goog
> > >
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/lima: fix recovering from PLBU out of memory
It looks like on PLBU_OUT_OF_MEM interrupt we need to resume from where we
stopped, i.e. new PLBU heap start is old end. Also update end address
in GP frame to grow heap on 2nd and subsequent out of memory interrupts.
Fixes: 2081e8dcf1ee ("drm/lima: recover task by enlarging heap buffer")
Signed-off-by: Vasily Khoruzhick
---
drivers/gpu/drm/lima/lima_gp.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/lima/lima_gp.c b/drivers/gpu/drm/lima/lima_gp.c
index d1e7826c2d74..325604262def 100644
--- a/drivers/gpu/drm/lima/lima_gp.c
+++ b/drivers/gpu/drm/lima/lima_gp.c
@@ -224,8 +224,13 @@ static int lima_gp_task_recover(struct lima_sched_pipe
*pipe)
}
gp_write(LIMA_GP_INT_MASK, LIMA_GP_IRQ_MASK_USED);
+ /* Resume from where we stopped, i.e. new start is old end */
+ gp_write(LIMA_GP_PLBU_ALLOC_START_ADDR,
+f[LIMA_GP_PLBU_ALLOC_END_ADDR >> 2]);
+ f[LIMA_GP_PLBU_ALLOC_END_ADDR >> 2] =
+ f[LIMA_GP_PLBU_ALLOC_START_ADDR >> 2] + task->heap->heap_size;
gp_write(LIMA_GP_PLBU_ALLOC_END_ADDR,
-f[LIMA_GP_PLBU_ALLOC_START_ADDR >> 2] + task->heap->heap_size);
+f[LIMA_GP_PLBU_ALLOC_END_ADDR >> 2]);
gp_write(LIMA_GP_CMD, LIMA_GP_CMD_UPDATE_PLBU_ALLOC);
return 0;
}
--
2.25.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/5] drm/virtio: track whether or not a context has been initiated
On Fri, Feb 14, 2020 at 11:27 AM Chia-I Wu wrote:
>
> On Thu, Feb 13, 2020 at 3:18 PM Gurchetan Singh
> wrote:
> >
> > Use an atomic variable to track whether a context has been
> > initiated.
> >
> > v2: Fix possible race (@olv)
> >
> > Signed-off-by: Gurchetan Singh
> > ---
> > drivers/gpu/drm/virtio/virtgpu_drv.h | 1 +
> > drivers/gpu/drm/virtio/virtgpu_ioctl.c | 3 +++
> > drivers/gpu/drm/virtio/virtgpu_kms.c | 1 +
> > 3 files changed, 5 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h
> > b/drivers/gpu/drm/virtio/virtgpu_drv.h
> > index 72c1d9b59dfe..ca505984f8ab 100644
> > --- a/drivers/gpu/drm/virtio/virtgpu_drv.h
> > +++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
> > @@ -209,6 +209,7 @@ struct virtio_gpu_device {
> >
> > struct virtio_gpu_fpriv {
> > uint32_t ctx_id;
> > + atomic_t context_initiated;
> > };
> >
> > /* virtio_ioctl.c */
> > diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
> > b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
> > index 896c3f419a6d..a98884462944 100644
> > --- a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
> > +++ b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
> > @@ -44,6 +44,9 @@ void virtio_gpu_create_context(struct drm_device *dev,
> > if (!vgdev->has_virgl_3d)
> > return;
> >
> > + if (!atomic_add_unless(>context_initiated, 1, 1))
> > + return;
> > +
> How does this work? When thread A and B enter this function at the
> same time, and thread B returns early, it is possible that thread B
> queues other commands before thread A has the chance to queue
> virtio_gpu_cmd_context_create.
Good catch, I'll add a spinlock in v3.
>
> > get_task_comm(dbgname, current);
> > virtio_gpu_cmd_context_create(vgdev, vfpriv->ctx_id,
> > strlen(dbgname), dbgname);
> > diff --git a/drivers/gpu/drm/virtio/virtgpu_kms.c
> > b/drivers/gpu/drm/virtio/virtgpu_kms.c
> > index 282558576527..25248bad3fc4 100644
> > --- a/drivers/gpu/drm/virtio/virtgpu_kms.c
> > +++ b/drivers/gpu/drm/virtio/virtgpu_kms.c
> > @@ -263,6 +263,7 @@ int virtio_gpu_driver_open(struct drm_device *dev,
> > struct drm_file *file)
> > }
> >
> > vfpriv->ctx_id = handle + 1;
> > + atomic_set(>context_initiated, 0);
> > file->driver_priv = vfpriv;
> > virtio_gpu_create_context(dev, file);
> > return 0;
> > --
> > 2.25.0.265.gbab2e86ba0-goog
> >
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/2] drm/bridge: anx7688: Add anx7688 bridge driver support
On Sat, Feb 15, 2020 at 5:36 AM Vasily Khoruzhick wrote: > > On Thu, Feb 13, 2020 at 6:54 AM Enric Balletbo i Serra > wrote: > > > > From: Nicolas Boichat > > > > ANX7688 is a HDMI to DP converter (as well as USB-C port controller), > > that has an internal microcontroller. > > > > The only reason a Linux kernel driver is necessary is to reject > > resolutions that require more bandwidth than what is available on > > the DP side. DP bandwidth and lane count are reported by the bridge > > via 2 registers on I2C. > > It is true only for your particular platform where usb-c part is > managed by firmware. Pinephone has the same anx7688 but linux will > need a driver that manages usb-c in addition to DP. > > I'd suggest making it MFD driver from the beginning, or at least make > proper bindings so we don't have to rework it and introduce binding > incompatibilities in future. If that helps for the binding, ANX7688 is indeed a MFD (TCPC, HDMI to DP converter, USB-C mux between USB 3.0 lanes and the DP output of the embedded converter), with 2 I2C addresses: - 0x2c is the TCPC/mux, used by the Embedded Controller [1] on Chrome OS, and the code in this patch (my understanding is that lane count/BW registers in the kernel driver below may only be available to FW on Chromebooks). - 0x28: - Used to update the embedded FW in the anx7688 (on Chrome OS we do this in depthcharge [2]). This is a EEPROM-based FW (so even without implementing this, it'll usually "just work"). - Used to workaround some TCPC issues (see [1] again). [1] EC driver: https://chromium.googlesource.com/chromiumos/platform/ec/+/refs/heads/master/driver/tcpm/anx7688.c [2] depthcharge driver to update ANX7688 FW: https://chromium.googlesource.com/chromiumos/platform/depthcharge/+/master/src/drivers/ec/anx7688/anx7688.c ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/2] drm/bridge: anx7688: Add anx7688 bridge driver support
On Fri, Feb 14, 2020 at 8:18 PM Andrzej Hajda wrote:
>
> On 13.02.2020 15:54, Enric Balletbo i Serra wrote:
> > From: Nicolas Boichat
> >
> > ANX7688 is a HDMI to DP converter (as well as USB-C port controller),
> > that has an internal microcontroller.
> >
> > The only reason a Linux kernel driver is necessary is to reject
> > resolutions that require more bandwidth than what is available on
> > the DP side. DP bandwidth and lane count are reported by the bridge
> > via 2 registers on I2C.
> >
> > Signed-off-by: Nicolas Boichat
> > Signed-off-by: Hsin-Yi Wang
> > Signed-off-by: Enric Balletbo i Serra
> > ---
> >
> > Changes in v2:
> > - Move driver to drivers/gpu/drm/bridge/analogix.
> > - Make the driver OF only so we can reduce the ifdefs.
> > - Update the Copyright to 2020.
> > - Use probe_new so we can get rid of the i2c_device_id table.
> >
> > drivers/gpu/drm/bridge/analogix/Kconfig | 12 ++
> > drivers/gpu/drm/bridge/analogix/Makefile | 1 +
> > .../drm/bridge/analogix/analogix-anx7688.c| 188 ++
> > 3 files changed, 201 insertions(+)
> > create mode 100644 drivers/gpu/drm/bridge/analogix/analogix-anx7688.c
> >
> > diff --git a/drivers/gpu/drm/bridge/analogix/Kconfig
> > b/drivers/gpu/drm/bridge/analogix/Kconfig
> > index e1fa7d820373..af7c2939403c 100644
> > --- a/drivers/gpu/drm/bridge/analogix/Kconfig
> > +++ b/drivers/gpu/drm/bridge/analogix/Kconfig
> > @@ -11,6 +11,18 @@ config DRM_ANALOGIX_ANX6345
> > ANX6345 transforms the LVTTL RGB output of an
> > application processor to eDP or DisplayPort.
> >
> > +config DRM_ANALOGIX_ANX7688
> > + tristate "Analogix ANX7688 bridge"
> > + depends on OF
> > + select DRM_KMS_HELPER
> > + select REGMAP_I2C
> > + help
> > + ANX7688 is an ultra-low power 4k Ultra-HD (4096x2160p60)
> > + mobile HD transmitter designed for portable devices. The
> > + ANX7688 converts HDMI 2.0 to DisplayPort 1.3 Ultra-HD
> > + including an intelligent crosspoint switch to support
> > + USB Type-C.
> > +
> > config DRM_ANALOGIX_ANX78XX
> > tristate "Analogix ANX78XX bridge"
> > select DRM_ANALOGIX_DP
> > diff --git a/drivers/gpu/drm/bridge/analogix/Makefile
> > b/drivers/gpu/drm/bridge/analogix/Makefile
> > index 97669b374098..27cd73635c8c 100644
> > --- a/drivers/gpu/drm/bridge/analogix/Makefile
> > +++ b/drivers/gpu/drm/bridge/analogix/Makefile
> > @@ -1,5 +1,6 @@
> > # SPDX-License-Identifier: GPL-2.0-only
> > analogix_dp-objs := analogix_dp_core.o analogix_dp_reg.o
> > analogix-i2c-dptx.o
> > obj-$(CONFIG_DRM_ANALOGIX_ANX6345) += analogix-anx6345.o
> > +obj-$(CONFIG_DRM_ANALOGIX_ANX7688) += analogix-anx7688.o
> > obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
> > obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix_dp.o
> > diff --git a/drivers/gpu/drm/bridge/analogix/analogix-anx7688.c
> > b/drivers/gpu/drm/bridge/analogix/analogix-anx7688.c
> > new file mode 100644
> > index ..10a7cd0f9126
> > --- /dev/null
> > +++ b/drivers/gpu/drm/bridge/analogix/analogix-anx7688.c
> > @@ -0,0 +1,188 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +/*
> > + * ANX7688 HDMI->DP bridge driver
> > + *
> > + * Copyright 2020 Google LLC
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +/* Register addresses */
> > +#define VENDOR_ID_REG 0x00
> > +#define DEVICE_ID_REG 0x02
> > +
> > +#define FW_VERSION_REG 0x80
> > +
> > +#define DP_BANDWIDTH_REG 0x85
> > +#define DP_LANE_COUNT_REG 0x86
> > +
> > +#define VENDOR_ID 0x1f29
> > +#define DEVICE_ID 0x7688
> > +
> > +/* First supported firmware version (0.85) */
> > +#define MINIMUM_FW_VERSION 0x0085
> > +
> > +struct anx7688 {
> > + struct drm_bridge bridge;
> > + struct i2c_client *client;
> > + struct regmap *regmap;
> > +
> > + bool filter;
> > +};
> > +
> > +static inline struct anx7688 *bridge_to_anx7688(struct drm_bridge *bridge)
> > +{
> > + return container_of(bridge, struct anx7688, bridge);
> > +}
> > +
> > +static bool anx7688_bridge_mode_fixup(struct drm_bridge *bridge,
> > + const struct drm_display_mode *mode,
> > + struct drm_display_mode *adjusted_mode)
> > +{
> > + struct anx7688 *anx7688 = bridge_to_anx7688(bridge);
> > + int totalbw, requiredbw;
> > + u8 dpbw, lanecount;
> > + u8 regs[2];
> > + int ret;
> > +
> > + if (!anx7688->filter)
> > + return true;
> > +
> > + /* Read both regs 0x85 (bandwidth) and 0x86 (lane count). */
> > + ret = regmap_bulk_read(anx7688->regmap, DP_BANDWIDTH_REG, regs, 2);
> > + if (ret < 0) {
> > + dev_err(>client->dev,
> > + "Failed to read bandwidth/lane count\n");
> > + return false;
> > + }
> > + dpbw = regs[0];
> > + lanecount = regs[1];
>
>
> Are these values hw invariant? Or they are result of cable probe/training?
>
> In 1st
Re: [PATCH AUTOSEL 5.5 155/542] drm/amdkfd: remove set but not used variable 'top_dev'
On Fri, Feb 14, 2020 at 04:44:29PM -0500, Greg KH wrote:
On Fri, Feb 14, 2020 at 10:42:27AM -0500, Sasha Levin wrote:
From: zhengbin
[ Upstream commit d191bd678153307573d615bb42da4fcca19fe477 ]
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/amd/amdkfd/kfd_iommu.c: In function kfd_iommu_device_init:
drivers/gpu/drm/amd/amdkfd/kfd_iommu.c:65:30: warning: variable top_dev set but
not used [-Wunused-but-set-variable]
Reported-by: Hulk Robot
Fixes: 1ae99eab34f9 ("drm/amdkfd: Initialize HSA_CAP_ATS_PRESENT capability in
topology codes")
Signed-off-by: zhengbin
Reviewed-by: Felix Kuehling
Signed-off-by: Felix Kuehling
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdkfd/kfd_iommu.c | 3 ---
1 file changed, 3 deletions(-)
Unless all of these "unused bt set variable" patches are needed for
"real" fixes, there's no need to add them here as we are NOT building
the kernel with that option enabled any time soon from what I can tell.
So you can drop a ton of these patches from all of these AUTOSEL
branches please.
Sigh, I confused the -Wno-unused-but-set-variable flag we pass in the
makefile with -Wunused-but-set-variable. Sorry about all this noise,
I'll drop it.
--
Thanks,
Sasha
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] drm/mst: Add support for simultaneous down replies
On Thu, 2020-02-13 at 16:15 -0500, Sean Paul wrote: > From: Sean Paul > > Hey all, > Earlier this week on my 5.5 kernel (I can't seem to get a 5.6 kernel to > behave on any of my devices), I ran into the multi-reply problem that > Wayne fixed in January. Without realizing there was already a fix > upstream, I went about solving it in different way. It wasn't until > rebasing the patches on 5.6 for the list that I realized there was > already a solution. > > At any rate, I think this way of handling things might be a bit more > performant. I'm not super happy with the cleanliness of the code, I > think this series should make things easier to read, but I don't think I > achieved that. So suggestions are welcome on how to break this apart. Honestly it looks a bit cleaner to me. Sideband message parsing in MST is pretty complex, so I'd think the code's probably always going to be messy to some extent. My only suggestion with cleaning things up - maybe we should stop calling it building a sideband reply, and call it re-assembling one? Seems a little less confusing, since we're really just taking the rx chunks and reassembling them into a full sideband message. I know at least I constantly find myself forgetting those functions are for rx and not tx. So, I will give my r-b for the whole series, but... Reviewed-by: Lyude Paul ...I think we should definitely look more into what Wayne's talking about before pushing this, and see if it's widespread enough of an issue to be a concern. It does kind of suck how slow MST probing can be, so I'd wonder if we could try your idea of rate limiting. My one concern there is I'm not actually sure if there's anything in the DP MST protocol that indicates how many messages a hub can handle at the same time - it's always supposed to just be two iirc. > Thanks, > > Sean > > Sean Paul (3): > drm/mst: Separate sideband packet header parsing from message building > drm/mst: Support simultaneous down replies > drm/dp_mst: Remove single tx msg restriction. > > drivers/gpu/drm/drm_dp_mst_topology.c | 196 ++ > include/drm/drm_dp_mst_helper.h | 65 - > 2 files changed, 137 insertions(+), 124 deletions(-) > -- Cheers, Lyude Paul (she/her) Associate Software Engineer at Red Hat ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/5] drm/nouveau/kms/gv100-: Add support for interlaced modes
We advertise being able to set interlaced modes, so let's actually make
sure to do that. Otherwise, we'll end up hanging the display engine due
to trying to set a mode with timings adjusted for interlacing without
telling the hardware it's actually an interlaced mode.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/dispnv50/headc37d.c | 5 +++--
drivers/gpu/drm/nouveau/dispnv50/headc57d.c | 5 +++--
drivers/gpu/drm/nouveau/nouveau_connector.c | 2 +-
3 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/headc37d.c
b/drivers/gpu/drm/nouveau/dispnv50/headc37d.c
index 00011ce109a6..4a9a32b89f74 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/headc37d.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/headc37d.c
@@ -168,14 +168,15 @@ headc37d_mode(struct nv50_head *head, struct
nv50_head_atom *asyh)
struct nv50_dmac *core = _disp(head->base.base.dev)->core->chan;
struct nv50_head_mode *m = >mode;
u32 *push;
- if ((push = evo_wait(core, 12))) {
+ if ((push = evo_wait(core, 13))) {
evo_mthd(push, 0x2064 + (head->base.index * 0x400), 5);
evo_data(push, (m->v.active << 16) | m->h.active );
evo_data(push, (m->v.synce << 16) | m->h.synce );
evo_data(push, (m->v.blanke << 16) | m->h.blanke );
evo_data(push, (m->v.blanks << 16) | m->h.blanks );
evo_data(push, (m->v.blank2e << 16) | m->v.blank2s);
- evo_mthd(push, 0x200c + (head->base.index * 0x400), 1);
+ evo_mthd(push, 0x2008 + (head->base.index * 0x400), 2);
+ evo_data(push, m->interlace);
evo_data(push, m->clock * 1000);
evo_mthd(push, 0x2028 + (head->base.index * 0x400), 1);
evo_data(push, m->clock * 1000);
diff --git a/drivers/gpu/drm/nouveau/dispnv50/headc57d.c
b/drivers/gpu/drm/nouveau/dispnv50/headc57d.c
index 938d910a1b1e..859131a8bc3c 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/headc57d.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/headc57d.c
@@ -173,14 +173,15 @@ headc57d_mode(struct nv50_head *head, struct
nv50_head_atom *asyh)
struct nv50_dmac *core = _disp(head->base.base.dev)->core->chan;
struct nv50_head_mode *m = >mode;
u32 *push;
- if ((push = evo_wait(core, 12))) {
+ if ((push = evo_wait(core, 13))) {
evo_mthd(push, 0x2064 + (head->base.index * 0x400), 5);
evo_data(push, (m->v.active << 16) | m->h.active );
evo_data(push, (m->v.synce << 16) | m->h.synce );
evo_data(push, (m->v.blanke << 16) | m->h.blanke );
evo_data(push, (m->v.blanks << 16) | m->h.blanks );
evo_data(push, (m->v.blank2e << 16) | m->v.blank2s);
- evo_mthd(push, 0x200c + (head->base.index * 0x400), 1);
+ evo_mthd(push, 0x2008 + (head->base.index * 0x400), 2);
+ evo_data(push, m->interlace);
evo_data(push, m->clock * 1000);
evo_mthd(push, 0x2028 + (head->base.index * 0x400), 1);
evo_data(push, m->clock * 1000);
diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c
b/drivers/gpu/drm/nouveau/nouveau_connector.c
index 43bcbb6d73c4..6dae00da5d7e 100644
--- a/drivers/gpu/drm/nouveau/nouveau_connector.c
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
@@ -1065,7 +1065,7 @@ nouveau_connector_mode_valid(struct drm_connector
*connector,
return get_slave_funcs(encoder)->mode_valid(encoder, mode);
case DCB_OUTPUT_DP:
if (mode->flags & DRM_MODE_FLAG_INTERLACE &&
- !nv_encoder->dp.caps.interlace)
+ !nv_encoder->caps.dp_interlace)
return MODE_NO_INTERLACE;
max_clock = nv_encoder->dp.link_nr;
--
2.24.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 4/5] drm/nouveau/kms/nv50-: Move 8BPC limit for MST into nv50_mstc_get_modes()
This just limits the BPC for MST connectors to a maximum of 8 from
nv50_mstc_get_modes(), instead of doing so during
nv50_msto_atomic_check(). This doesn't introduce any functional changes
yet (other then userspace now lying about the max bpc, but we can't
support that yet anyway so meh). But, we'll need this in a moment so
that we can share mode validation between SST and MST which will fix
some real world issues.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 25 ++---
1 file changed, 14 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index cab92de3da90..020058811831 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -903,15 +903,9 @@ nv50_msto_atomic_check(struct drm_encoder *encoder,
if (!state->duplicated) {
const int clock = crtc_state->adjusted_mode.clock;
- /*
-* XXX: Since we don't use HDR in userspace quite yet, limit
-* the bpc to 8 to save bandwidth on the topology. In the
-* future, we'll want to properly fix this by dynamically
-* selecting the highest possible bpc that would fit in the
-* topology
-*/
- asyh->or.bpc = min(connector->display_info.bpc, 8U);
- asyh->dp.pbn = drm_dp_calc_pbn_mode(clock, asyh->or.bpc * 3,
false);
+ asyh->or.bpc = connector->display_info.bpc;
+ asyh->dp.pbn = drm_dp_calc_pbn_mode(clock, asyh->or.bpc * 3,
+ false);
}
slots = drm_dp_atomic_find_vcpi_slots(state, >mgr, mstc->port,
@@ -1071,8 +1065,17 @@ nv50_mstc_get_modes(struct drm_connector *connector)
if (mstc->edid)
ret = drm_add_edid_modes(>connector, mstc->edid);
- if (!mstc->connector.display_info.bpc)
- mstc->connector.display_info.bpc = 8;
+ /*
+* XXX: Since we don't use HDR in userspace quite yet, limit the bpc
+* to 8 to save bandwidth on the topology. In the future, we'll want
+* to properly fix this by dynamically selecting the highest possible
+* bpc that would fit in the topology
+*/
+ if (connector->display_info.bpc)
+ connector->display_info.bpc =
+ clamp(connector->display_info.bpc, 6U, 8U);
+ else
+ connector->display_info.bpc = 8;
if (mstc->native)
drm_mode_destroy(mstc->connector.dev, mstc->native);
--
2.24.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/5] drm/nouveau/kms/nv50-: Probe SOR caps for DP interlacing support
Right now, we make the mistake of allowing interlacing on all
connectors. Nvidia hardware does not always support interlacing with DP
though, so we need to make sure that we don't allow interlaced modes to
be set in such situations as otherwise we'll end up accidentally hanging
the display HW.
This fixes some hangs with Turing, which would be caused by attempting
to set an interlaced mode on hardware that doesn't support it. This
patch likely fixes other hardware hanging in the same way as well.
Changes since v1:
* Actually probe caps correctly this time, both on EVO and NVDisplay.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/dispnv50/core.h | 3 +++
drivers/gpu/drm/nouveau/dispnv50/core507d.c | 15
drivers/gpu/drm/nouveau/dispnv50/core827d.c | 1 +
drivers/gpu/drm/nouveau/dispnv50/core907d.c | 1 +
drivers/gpu/drm/nouveau/dispnv50/core917d.c | 1 +
drivers/gpu/drm/nouveau/dispnv50/corec37d.c | 26 +
drivers/gpu/drm/nouveau/dispnv50/corec57d.c | 1 +
drivers/gpu/drm/nouveau/dispnv50/disp.c | 21 -
drivers/gpu/drm/nouveau/dispnv50/disp.h | 1 +
drivers/gpu/drm/nouveau/nouveau_connector.c | 10 +++-
drivers/gpu/drm/nouveau/nouveau_encoder.h | 4
11 files changed, 82 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/core.h
b/drivers/gpu/drm/nouveau/dispnv50/core.h
index ff94f3f6f264..9a1f610e4c81 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/core.h
+++ b/drivers/gpu/drm/nouveau/dispnv50/core.h
@@ -15,6 +15,7 @@ void nv50_core_del(struct nv50_core **);
struct nv50_core_func {
void (*init)(struct nv50_core *);
void (*ntfy_init)(struct nouveau_bo *, u32 offset);
+ int (*caps_init)(struct nouveau_drm *, struct nv50_disp *);
int (*ntfy_wait_done)(struct nouveau_bo *, u32 offset,
struct nvif_device *);
void (*update)(struct nv50_core *, u32 *interlock, bool ntfy);
@@ -35,6 +36,7 @@ int core507d_new_(const struct nv50_core_func *, struct
nouveau_drm *, s32,
struct nv50_core **);
void core507d_init(struct nv50_core *);
void core507d_ntfy_init(struct nouveau_bo *, u32);
+int core507d_caps_init(struct nouveau_drm *, struct nv50_disp *);
int core507d_ntfy_wait_done(struct nouveau_bo *, u32, struct nvif_device *);
void core507d_update(struct nv50_core *, u32 *, bool);
@@ -51,6 +53,7 @@ extern const struct nv50_outp_func sor907d;
int core917d_new(struct nouveau_drm *, s32, struct nv50_core **);
int corec37d_new(struct nouveau_drm *, s32, struct nv50_core **);
+int corec37d_caps_init(struct nouveau_drm *, struct nv50_disp *);
int corec37d_ntfy_wait_done(struct nouveau_bo *, u32, struct nvif_device *);
void corec37d_update(struct nv50_core *, u32 *, bool);
void corec37d_wndw_owner(struct nv50_core *);
diff --git a/drivers/gpu/drm/nouveau/dispnv50/core507d.c
b/drivers/gpu/drm/nouveau/dispnv50/core507d.c
index e7fcfa6e6467..cd45dc09d457 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/core507d.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/core507d.c
@@ -61,6 +61,20 @@ core507d_ntfy_init(struct nouveau_bo *bo, u32 offset)
nouveau_bo_wr32(bo, offset / 4, 0x);
}
+int
+core507d_caps_init(struct nouveau_drm *drm, struct nv50_disp *disp)
+{
+ u32 *push = evo_wait(>core->chan, 2);
+
+ if (push) {
+ evo_mthd(push, 0x008c, 1);
+ evo_data(push, 0x0);
+ evo_kick(push, >core->chan);
+ }
+
+ return 0;
+}
+
void
core507d_init(struct nv50_core *core)
{
@@ -76,6 +90,7 @@ static const struct nv50_core_func
core507d = {
.init = core507d_init,
.ntfy_init = core507d_ntfy_init,
+ .caps_init = core507d_caps_init,
.ntfy_wait_done = core507d_ntfy_wait_done,
.update = core507d_update,
.head = ,
diff --git a/drivers/gpu/drm/nouveau/dispnv50/core827d.c
b/drivers/gpu/drm/nouveau/dispnv50/core827d.c
index 6123a068f836..2e0c1c536afe 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/core827d.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/core827d.c
@@ -26,6 +26,7 @@ static const struct nv50_core_func
core827d = {
.init = core507d_init,
.ntfy_init = core507d_ntfy_init,
+ .caps_init = core507d_caps_init,
.ntfy_wait_done = core507d_ntfy_wait_done,
.update = core507d_update,
.head = ,
diff --git a/drivers/gpu/drm/nouveau/dispnv50/core907d.c
b/drivers/gpu/drm/nouveau/dispnv50/core907d.c
index ef822f813435..271629832629 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/core907d.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/core907d.c
@@ -26,6 +26,7 @@ static const struct nv50_core_func
core907d = {
.init = core507d_init,
.ntfy_init = core507d_ntfy_init,
+ .caps_init = core507d_caps_init,
.ntfy_wait_done = core507d_ntfy_wait_done,
.update = core507d_update,
.head = ,
diff --git a/drivers/gpu/drm/nouveau/dispnv50/core917d.c
[PATCH v2 5/5] drm/nouveau/kms/nv50-: Share DP SST mode_valid() handling with MST
Currently, the nv50_mstc_mode_valid() function is happy to take any and
all modes, even the ones we can't actually support sometimes like
interlaced modes.
Luckily, the only difference between the mode validation that needs to
be performed for MST vs. SST is that eventually we'll need to check the
minimum PBN against the MSTB's full PBN capabilities (remember-we don't
care about the current bw state here). Otherwise, all of the other code
can be shared.
So, we move all of the common mode validation in
nouveau_connector_mode_valid() into a separate helper,
nv50_dp_mode_valid(), and use that from both nv50_mstc_mode_valid() and
nouveau_connector_mode_valid(). Note that we allow for returning the
calculated clock that nv50_dp_mode_valid() came up with, since we'll
eventually want to use that for PBN calculation in
nv50_mstc_mode_valid().
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 9 -
drivers/gpu/drm/nouveau/nouveau_connector.c | 41 +++--
drivers/gpu/drm/nouveau/nouveau_connector.h | 5 +++
drivers/gpu/drm/nouveau/nouveau_dp.c| 31
drivers/gpu/drm/nouveau/nouveau_encoder.h | 4 ++
5 files changed, 70 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index 020058811831..684e2c081ea2 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -1051,7 +1051,14 @@ static enum drm_mode_status
nv50_mstc_mode_valid(struct drm_connector *connector,
struct drm_display_mode *mode)
{
- return MODE_OK;
+ struct nv50_mstc *mstc = nv50_mstc(connector);
+ struct nouveau_encoder *outp = mstc->mstm->outp;
+
+ /* TODO: calculate the PBN from the dotclock and validate against the
+* MSTB's max possible PBN
+*/
+
+ return nv50_dp_mode_valid(connector, outp, mode, NULL);
}
static int
diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c
b/drivers/gpu/drm/nouveau/nouveau_connector.c
index 6dae00da5d7e..a82a51661ca1 100644
--- a/drivers/gpu/drm/nouveau/nouveau_connector.c
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
@@ -38,6 +38,7 @@
#include "nouveau_reg.h"
#include "nouveau_drv.h"
#include "dispnv04/hw.h"
+#include "dispnv50/disp.h"
#include "nouveau_acpi.h"
#include "nouveau_display.h"
@@ -1033,6 +1034,24 @@ get_tmds_link_bandwidth(struct drm_connector *connector)
return 112000 * duallink_scale;
}
+enum drm_mode_status
+nouveau_conn_mode_clock_valid(const struct drm_display_mode *mode,
+ const unsigned min_clock,
+ const unsigned max_clock,
+ unsigned *clock)
+{
+ if ((mode->flags & DRM_MODE_FLAG_3D_MASK) ==
+ DRM_MODE_FLAG_3D_FRAME_PACKING)
+ *clock *= 2;
+
+ if (*clock < min_clock)
+ return MODE_CLOCK_LOW;
+ if (*clock > max_clock)
+ return MODE_CLOCK_HIGH;
+
+ return MODE_OK;
+}
+
static enum drm_mode_status
nouveau_connector_mode_valid(struct drm_connector *connector,
struct drm_display_mode *mode)
@@ -1041,7 +1060,6 @@ nouveau_connector_mode_valid(struct drm_connector
*connector,
struct nouveau_encoder *nv_encoder = nv_connector->detected_encoder;
struct drm_encoder *encoder = to_drm_encoder(nv_encoder);
unsigned min_clock = 25000, max_clock = min_clock;
- unsigned clock = mode->clock;
switch (nv_encoder->dcb->type) {
case DCB_OUTPUT_LVDS:
@@ -1064,29 +1082,14 @@ nouveau_connector_mode_valid(struct drm_connector
*connector,
case DCB_OUTPUT_TV:
return get_slave_funcs(encoder)->mode_valid(encoder, mode);
case DCB_OUTPUT_DP:
- if (mode->flags & DRM_MODE_FLAG_INTERLACE &&
- !nv_encoder->caps.dp_interlace)
- return MODE_NO_INTERLACE;
-
- max_clock = nv_encoder->dp.link_nr;
- max_clock *= nv_encoder->dp.link_bw;
- clock = clock * (connector->display_info.bpc * 3) / 10;
- break;
+ return nv50_dp_mode_valid(connector, nv_encoder, mode, NULL);
default:
BUG();
return MODE_BAD;
}
- if ((mode->flags & DRM_MODE_FLAG_3D_MASK) ==
DRM_MODE_FLAG_3D_FRAME_PACKING)
- clock *= 2;
-
- if (clock < min_clock)
- return MODE_CLOCK_LOW;
-
- if (clock > max_clock)
- return MODE_CLOCK_HIGH;
-
- return MODE_OK;
+ return nouveau_conn_mode_clock_valid(mode, min_clock, max_clock,
+NULL);
}
static struct drm_encoder *
diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.h
b/drivers/gpu/drm/nouveau/nouveau_connector.h
index de84fb4708c7..9e062c7adec8 100644
---
[PATCH v2 0/5] drm/nouveau: DP interlace fixes
Currently, nouveau doesn't actually bother to try probing whether or not it can actually handle interlaced modes over DisplayPort. As a result, on volta and later we'll end up trying to set an interlaced mode even when it's not supported and cause the front end for the display engine to hang. So, let's teach nouveau to reject interlaced modes on hardware that can't actually handle it. Additionally for MST, since we accomplish this by simply reusing more of the SST mode validation we also get (some) basic bw validation for modes we detect on MST connectors completely for free. Lyude Paul (5): drm/nouveau/kms/nv50-: Initialize core channel in nouveau_display_create() drm/nouveau/kms/nv50-: Probe SOR caps for DP interlacing support drm/nouveau/kms/gv100-: Add support for interlaced modes drm/nouveau/kms/nv50-: Move 8BPC limit for MST into nv50_mstc_get_modes() drm/nouveau/kms/nv50-: Share DP SST mode_valid() handling with MST drivers/gpu/drm/nouveau/dispnv50/core.h | 3 ++ drivers/gpu/drm/nouveau/dispnv50/core507d.c | 15 ++ drivers/gpu/drm/nouveau/dispnv50/core827d.c | 1 + drivers/gpu/drm/nouveau/dispnv50/core907d.c | 1 + drivers/gpu/drm/nouveau/dispnv50/core917d.c | 1 + drivers/gpu/drm/nouveau/dispnv50/corec37d.c | 26 + drivers/gpu/drm/nouveau/dispnv50/corec57d.c | 1 + drivers/gpu/drm/nouveau/dispnv50/disp.c | 60 - drivers/gpu/drm/nouveau/dispnv50/disp.h | 1 + drivers/gpu/drm/nouveau/dispnv50/headc37d.c | 5 +- drivers/gpu/drm/nouveau/dispnv50/headc57d.c | 5 +- drivers/gpu/drm/nouveau/nouveau_connector.c | 43 +-- drivers/gpu/drm/nouveau/nouveau_connector.h | 5 ++ drivers/gpu/drm/nouveau/nouveau_dp.c| 31 +++ drivers/gpu/drm/nouveau/nouveau_encoder.h | 8 +++ 15 files changed, 172 insertions(+), 34 deletions(-) -- 2.24.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/5] drm/nouveau/kms/nv50-: Initialize core channel in nouveau_display_create()
We'll need the core channel initialized and ready by the time that we
start creating modesetting objects, so that we can call the
NV507D_GET_CAPABILITIES method to make the hardware expose it's
modesetting capabilities for later probing.
So, when loading the driver prepare the core channel from within
nouveau_display_create(). Everywhere else, we initialize the core
channel during resume.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index a3dc2ba19fb2..ba07b0154d2b 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -2394,7 +2394,8 @@ nv50_display_init(struct drm_device *dev, bool resume,
bool runtime)
struct drm_encoder *encoder;
struct drm_plane *plane;
- core->func->init(core);
+ if (resume || runtime)
+ core->func->init(core);
list_for_each_entry(encoder, >mode_config.encoder_list, head) {
if (encoder->encoder_type != DRM_MODE_ENCODER_DPMST) {
@@ -2481,6 +2482,8 @@ nv50_display_create(struct drm_device *dev)
if (ret)
goto out;
+ disp->core->func->init(disp->core);
+
/* create crtc objects to represent the hw heads */
if (disp->disp->object.oclass >= GV100_DISP)
crtcs = nvif_rd32(>object, 0x610060) & 0xff;
--
2.24.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/2] drm/bridge: anx7688: Add anx7688 bridge driver support
On Fri, Feb 14, 2020 at 2:20 PM Enric Balletbo Serra wrote: > > Hi Vasily, > > Missatge de Vasily Khoruzhick del dia dv., 14 de > febr. 2020 a les 23:17: > > > > On Fri, Feb 14, 2020 at 1:53 PM Enric Balletbo Serra > > wrote: > > > > > > Hi Vasily, > > > > > > Missatge de Vasily Khoruzhick del dia dv., 14 de > > > febr. 2020 a les 22:36: > > > > > > > > On Thu, Feb 13, 2020 at 6:54 AM Enric Balletbo i Serra > > > > wrote: > > > > > > > > > > From: Nicolas Boichat > > > > > > > > > > ANX7688 is a HDMI to DP converter (as well as USB-C port controller), > > > > > that has an internal microcontroller. > > > > > > > > > > The only reason a Linux kernel driver is necessary is to reject > > > > > resolutions that require more bandwidth than what is available on > > > > > the DP side. DP bandwidth and lane count are reported by the bridge > > > > > via 2 registers on I2C. > > > > > > > > It is true only for your particular platform where usb-c part is > > > > managed by firmware. Pinephone has the same anx7688 but linux will > > > > need a driver that manages usb-c in addition to DP. > > > > > > > > I'd suggest making it MFD driver from the beginning, or at least make > > > > proper bindings so we don't have to rework it and introduce binding > > > > incompatibilities in future. > > > > > > > > > > Do you have example code on how the ANX7866 is used in pinephone? > > > There is a repo somewhere? > > > > I don't think it's implemented yet. I've CCed Icenowy in case if she > > has anything. > > > > It would be good to join the effort. Just because I am curious, there > are public schematics for the pinephone that is using that bridge? Schematics is available here: https://wiki.pine64.org/index.php/PinePhone_v1.1_-_Braveheart#Schematic > > > Thanks, > > > Enric > > > > > > > > Signed-off-by: Nicolas Boichat > > > > > Signed-off-by: Hsin-Yi Wang > > > > > Signed-off-by: Enric Balletbo i Serra > > > > > --- > > > > > > > > > > Changes in v2: > > > > > - Move driver to drivers/gpu/drm/bridge/analogix. > > > > > - Make the driver OF only so we can reduce the ifdefs. > > > > > - Update the Copyright to 2020. > > > > > - Use probe_new so we can get rid of the i2c_device_id table. > > > > > > > > > > drivers/gpu/drm/bridge/analogix/Kconfig | 12 ++ > > > > > drivers/gpu/drm/bridge/analogix/Makefile | 1 + > > > > > .../drm/bridge/analogix/analogix-anx7688.c| 188 > > > > > ++ > > > > > 3 files changed, 201 insertions(+) > > > > > create mode 100644 drivers/gpu/drm/bridge/analogix/analogix-anx7688.c > > > > > > > > > > diff --git a/drivers/gpu/drm/bridge/analogix/Kconfig > > > > > b/drivers/gpu/drm/bridge/analogix/Kconfig > > > > > index e1fa7d820373..af7c2939403c 100644 > > > > > --- a/drivers/gpu/drm/bridge/analogix/Kconfig > > > > > +++ b/drivers/gpu/drm/bridge/analogix/Kconfig > > > > > @@ -11,6 +11,18 @@ config DRM_ANALOGIX_ANX6345 > > > > > ANX6345 transforms the LVTTL RGB output of an > > > > > application processor to eDP or DisplayPort. > > > > > > > > > > +config DRM_ANALOGIX_ANX7688 > > > > > + tristate "Analogix ANX7688 bridge" > > > > > + depends on OF > > > > > + select DRM_KMS_HELPER > > > > > + select REGMAP_I2C > > > > > + help > > > > > + ANX7688 is an ultra-low power 4k Ultra-HD (4096x2160p60) > > > > > + mobile HD transmitter designed for portable devices. The > > > > > + ANX7688 converts HDMI 2.0 to DisplayPort 1.3 Ultra-HD > > > > > + including an intelligent crosspoint switch to support > > > > > + USB Type-C. > > > > > + > > > > > config DRM_ANALOGIX_ANX78XX > > > > > tristate "Analogix ANX78XX bridge" > > > > > select DRM_ANALOGIX_DP > > > > > diff --git a/drivers/gpu/drm/bridge/analogix/Makefile > > > > > b/drivers/gpu/drm/bridge/analogix/Makefile > > > > > index 97669b374098..27cd73635c8c 100644 > > > > > --- a/drivers/gpu/drm/bridge/analogix/Makefile > > > > > +++ b/drivers/gpu/drm/bridge/analogix/Makefile > > > > > @@ -1,5 +1,6 @@ > > > > > # SPDX-License-Identifier: GPL-2.0-only > > > > > analogix_dp-objs := analogix_dp_core.o analogix_dp_reg.o > > > > > analogix-i2c-dptx.o > > > > > obj-$(CONFIG_DRM_ANALOGIX_ANX6345) += analogix-anx6345.o > > > > > +obj-$(CONFIG_DRM_ANALOGIX_ANX7688) += analogix-anx7688.o > > > > > obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o > > > > > obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix_dp.o > > > > > diff --git a/drivers/gpu/drm/bridge/analogix/analogix-anx7688.c > > > > > b/drivers/gpu/drm/bridge/analogix/analogix-anx7688.c > > > > > new file mode 100644 > > > > > index ..10a7cd0f9126 > > > > > --- /dev/null > > > > > +++ b/drivers/gpu/drm/bridge/analogix/analogix-anx7688.c > > > > > @@ -0,0 +1,188 @@ > > > > > +// SPDX-License-Identifier: GPL-2.0-only > > > > > +/* > > > > > + * ANX7688 HDMI->DP bridge driver > > > > > + * > > > > > + * Copyright 2020 Google LLC > > > > > + */ > >
Re: [PATCH v2 2/2] drm/bridge: anx7688: Add anx7688 bridge driver support
Hi Vasily, Missatge de Vasily Khoruzhick del dia dv., 14 de febr. 2020 a les 23:17: > > On Fri, Feb 14, 2020 at 1:53 PM Enric Balletbo Serra > wrote: > > > > Hi Vasily, > > > > Missatge de Vasily Khoruzhick del dia dv., 14 de > > febr. 2020 a les 22:36: > > > > > > On Thu, Feb 13, 2020 at 6:54 AM Enric Balletbo i Serra > > > wrote: > > > > > > > > From: Nicolas Boichat > > > > > > > > ANX7688 is a HDMI to DP converter (as well as USB-C port controller), > > > > that has an internal microcontroller. > > > > > > > > The only reason a Linux kernel driver is necessary is to reject > > > > resolutions that require more bandwidth than what is available on > > > > the DP side. DP bandwidth and lane count are reported by the bridge > > > > via 2 registers on I2C. > > > > > > It is true only for your particular platform where usb-c part is > > > managed by firmware. Pinephone has the same anx7688 but linux will > > > need a driver that manages usb-c in addition to DP. > > > > > > I'd suggest making it MFD driver from the beginning, or at least make > > > proper bindings so we don't have to rework it and introduce binding > > > incompatibilities in future. > > > > > > > Do you have example code on how the ANX7866 is used in pinephone? > > There is a repo somewhere? > > I don't think it's implemented yet. I've CCed Icenowy in case if she > has anything. > It would be good to join the effort. Just because I am curious, there are public schematics for the pinephone that is using that bridge? > > Thanks, > > Enric > > > > > > Signed-off-by: Nicolas Boichat > > > > Signed-off-by: Hsin-Yi Wang > > > > Signed-off-by: Enric Balletbo i Serra > > > > --- > > > > > > > > Changes in v2: > > > > - Move driver to drivers/gpu/drm/bridge/analogix. > > > > - Make the driver OF only so we can reduce the ifdefs. > > > > - Update the Copyright to 2020. > > > > - Use probe_new so we can get rid of the i2c_device_id table. > > > > > > > > drivers/gpu/drm/bridge/analogix/Kconfig | 12 ++ > > > > drivers/gpu/drm/bridge/analogix/Makefile | 1 + > > > > .../drm/bridge/analogix/analogix-anx7688.c| 188 ++ > > > > 3 files changed, 201 insertions(+) > > > > create mode 100644 drivers/gpu/drm/bridge/analogix/analogix-anx7688.c > > > > > > > > diff --git a/drivers/gpu/drm/bridge/analogix/Kconfig > > > > b/drivers/gpu/drm/bridge/analogix/Kconfig > > > > index e1fa7d820373..af7c2939403c 100644 > > > > --- a/drivers/gpu/drm/bridge/analogix/Kconfig > > > > +++ b/drivers/gpu/drm/bridge/analogix/Kconfig > > > > @@ -11,6 +11,18 @@ config DRM_ANALOGIX_ANX6345 > > > > ANX6345 transforms the LVTTL RGB output of an > > > > application processor to eDP or DisplayPort. > > > > > > > > +config DRM_ANALOGIX_ANX7688 > > > > + tristate "Analogix ANX7688 bridge" > > > > + depends on OF > > > > + select DRM_KMS_HELPER > > > > + select REGMAP_I2C > > > > + help > > > > + ANX7688 is an ultra-low power 4k Ultra-HD (4096x2160p60) > > > > + mobile HD transmitter designed for portable devices. The > > > > + ANX7688 converts HDMI 2.0 to DisplayPort 1.3 Ultra-HD > > > > + including an intelligent crosspoint switch to support > > > > + USB Type-C. > > > > + > > > > config DRM_ANALOGIX_ANX78XX > > > > tristate "Analogix ANX78XX bridge" > > > > select DRM_ANALOGIX_DP > > > > diff --git a/drivers/gpu/drm/bridge/analogix/Makefile > > > > b/drivers/gpu/drm/bridge/analogix/Makefile > > > > index 97669b374098..27cd73635c8c 100644 > > > > --- a/drivers/gpu/drm/bridge/analogix/Makefile > > > > +++ b/drivers/gpu/drm/bridge/analogix/Makefile > > > > @@ -1,5 +1,6 @@ > > > > # SPDX-License-Identifier: GPL-2.0-only > > > > analogix_dp-objs := analogix_dp_core.o analogix_dp_reg.o > > > > analogix-i2c-dptx.o > > > > obj-$(CONFIG_DRM_ANALOGIX_ANX6345) += analogix-anx6345.o > > > > +obj-$(CONFIG_DRM_ANALOGIX_ANX7688) += analogix-anx7688.o > > > > obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o > > > > obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix_dp.o > > > > diff --git a/drivers/gpu/drm/bridge/analogix/analogix-anx7688.c > > > > b/drivers/gpu/drm/bridge/analogix/analogix-anx7688.c > > > > new file mode 100644 > > > > index ..10a7cd0f9126 > > > > --- /dev/null > > > > +++ b/drivers/gpu/drm/bridge/analogix/analogix-anx7688.c > > > > @@ -0,0 +1,188 @@ > > > > +// SPDX-License-Identifier: GPL-2.0-only > > > > +/* > > > > + * ANX7688 HDMI->DP bridge driver > > > > + * > > > > + * Copyright 2020 Google LLC > > > > + */ > > > > + > > > > +#include > > > > +#include > > > > +#include > > > > +#include > > > > + > > > > +/* Register addresses */ > > > > +#define VENDOR_ID_REG 0x00 > > > > +#define DEVICE_ID_REG 0x02 > > > > + > > > > +#define FW_VERSION_REG 0x80 > > > > + > > > > +#define DP_BANDWIDTH_REG 0x85 > > > > +#define DP_LANE_COUNT_REG 0x86 > > > > + > > > > +#define VENDOR_ID 0x1f29 > > > > +#define
Re: [PATCH v2 2/2] drm/bridge: anx7688: Add anx7688 bridge driver support
On Fri, Feb 14, 2020 at 1:53 PM Enric Balletbo Serra
wrote:
>
> Hi Vasily,
>
> Missatge de Vasily Khoruzhick del dia dv., 14 de
> febr. 2020 a les 22:36:
> >
> > On Thu, Feb 13, 2020 at 6:54 AM Enric Balletbo i Serra
> > wrote:
> > >
> > > From: Nicolas Boichat
> > >
> > > ANX7688 is a HDMI to DP converter (as well as USB-C port controller),
> > > that has an internal microcontroller.
> > >
> > > The only reason a Linux kernel driver is necessary is to reject
> > > resolutions that require more bandwidth than what is available on
> > > the DP side. DP bandwidth and lane count are reported by the bridge
> > > via 2 registers on I2C.
> >
> > It is true only for your particular platform where usb-c part is
> > managed by firmware. Pinephone has the same anx7688 but linux will
> > need a driver that manages usb-c in addition to DP.
> >
> > I'd suggest making it MFD driver from the beginning, or at least make
> > proper bindings so we don't have to rework it and introduce binding
> > incompatibilities in future.
> >
>
> Do you have example code on how the ANX7866 is used in pinephone?
> There is a repo somewhere?
I don't think it's implemented yet. I've CCed Icenowy in case if she
has anything.
> Thanks,
> Enric
>
> > > Signed-off-by: Nicolas Boichat
> > > Signed-off-by: Hsin-Yi Wang
> > > Signed-off-by: Enric Balletbo i Serra
> > > ---
> > >
> > > Changes in v2:
> > > - Move driver to drivers/gpu/drm/bridge/analogix.
> > > - Make the driver OF only so we can reduce the ifdefs.
> > > - Update the Copyright to 2020.
> > > - Use probe_new so we can get rid of the i2c_device_id table.
> > >
> > > drivers/gpu/drm/bridge/analogix/Kconfig | 12 ++
> > > drivers/gpu/drm/bridge/analogix/Makefile | 1 +
> > > .../drm/bridge/analogix/analogix-anx7688.c| 188 ++
> > > 3 files changed, 201 insertions(+)
> > > create mode 100644 drivers/gpu/drm/bridge/analogix/analogix-anx7688.c
> > >
> > > diff --git a/drivers/gpu/drm/bridge/analogix/Kconfig
> > > b/drivers/gpu/drm/bridge/analogix/Kconfig
> > > index e1fa7d820373..af7c2939403c 100644
> > > --- a/drivers/gpu/drm/bridge/analogix/Kconfig
> > > +++ b/drivers/gpu/drm/bridge/analogix/Kconfig
> > > @@ -11,6 +11,18 @@ config DRM_ANALOGIX_ANX6345
> > > ANX6345 transforms the LVTTL RGB output of an
> > > application processor to eDP or DisplayPort.
> > >
> > > +config DRM_ANALOGIX_ANX7688
> > > + tristate "Analogix ANX7688 bridge"
> > > + depends on OF
> > > + select DRM_KMS_HELPER
> > > + select REGMAP_I2C
> > > + help
> > > + ANX7688 is an ultra-low power 4k Ultra-HD (4096x2160p60)
> > > + mobile HD transmitter designed for portable devices. The
> > > + ANX7688 converts HDMI 2.0 to DisplayPort 1.3 Ultra-HD
> > > + including an intelligent crosspoint switch to support
> > > + USB Type-C.
> > > +
> > > config DRM_ANALOGIX_ANX78XX
> > > tristate "Analogix ANX78XX bridge"
> > > select DRM_ANALOGIX_DP
> > > diff --git a/drivers/gpu/drm/bridge/analogix/Makefile
> > > b/drivers/gpu/drm/bridge/analogix/Makefile
> > > index 97669b374098..27cd73635c8c 100644
> > > --- a/drivers/gpu/drm/bridge/analogix/Makefile
> > > +++ b/drivers/gpu/drm/bridge/analogix/Makefile
> > > @@ -1,5 +1,6 @@
> > > # SPDX-License-Identifier: GPL-2.0-only
> > > analogix_dp-objs := analogix_dp_core.o analogix_dp_reg.o
> > > analogix-i2c-dptx.o
> > > obj-$(CONFIG_DRM_ANALOGIX_ANX6345) += analogix-anx6345.o
> > > +obj-$(CONFIG_DRM_ANALOGIX_ANX7688) += analogix-anx7688.o
> > > obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
> > > obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix_dp.o
> > > diff --git a/drivers/gpu/drm/bridge/analogix/analogix-anx7688.c
> > > b/drivers/gpu/drm/bridge/analogix/analogix-anx7688.c
> > > new file mode 100644
> > > index ..10a7cd0f9126
> > > --- /dev/null
> > > +++ b/drivers/gpu/drm/bridge/analogix/analogix-anx7688.c
> > > @@ -0,0 +1,188 @@
> > > +// SPDX-License-Identifier: GPL-2.0-only
> > > +/*
> > > + * ANX7688 HDMI->DP bridge driver
> > > + *
> > > + * Copyright 2020 Google LLC
> > > + */
> > > +
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +
> > > +/* Register addresses */
> > > +#define VENDOR_ID_REG 0x00
> > > +#define DEVICE_ID_REG 0x02
> > > +
> > > +#define FW_VERSION_REG 0x80
> > > +
> > > +#define DP_BANDWIDTH_REG 0x85
> > > +#define DP_LANE_COUNT_REG 0x86
> > > +
> > > +#define VENDOR_ID 0x1f29
> > > +#define DEVICE_ID 0x7688
> > > +
> > > +/* First supported firmware version (0.85) */
> > > +#define MINIMUM_FW_VERSION 0x0085
> > > +
> > > +struct anx7688 {
> > > + struct drm_bridge bridge;
> > > + struct i2c_client *client;
> > > + struct regmap *regmap;
> > > +
> > > + bool filter;
> > > +};
> > > +
> > > +static inline struct anx7688 *bridge_to_anx7688(struct drm_bridge
> > > *bridge)
> > > +{
> > > + return container_of(bridge, struct anx7688,
Re: [RFC PATCH 0/3] KVM: x86: honor guest memory type
On Fri, Feb 14, 2020 at 01:56:48PM -0800, Jim Mattson wrote: > On Fri, Feb 14, 2020 at 1:47 PM Chia-I Wu wrote: > > AFAICT, it is currently allowed on ARM (verified) and AMD (not > > verified, but svm_get_mt_mask returns 0 which supposedly means the NPT > > does not restrict what the guest PAT can do). This diff would do the > > trick for Intel without needing any uapi change: > > I would be concerned about Intel CPU errata such as SKX40 and SKX59. The part KVM cares about, #MC, is already addressed by forcing UC for MMIO. The data corruption issue is on the guest kernel to correctly use WC and/or non-temporal writes. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/2] drm/bridge: anx7688: Add anx7688 bridge driver support
Hi Vasily,
Missatge de Vasily Khoruzhick del dia dv., 14 de
febr. 2020 a les 22:36:
>
> On Thu, Feb 13, 2020 at 6:54 AM Enric Balletbo i Serra
> wrote:
> >
> > From: Nicolas Boichat
> >
> > ANX7688 is a HDMI to DP converter (as well as USB-C port controller),
> > that has an internal microcontroller.
> >
> > The only reason a Linux kernel driver is necessary is to reject
> > resolutions that require more bandwidth than what is available on
> > the DP side. DP bandwidth and lane count are reported by the bridge
> > via 2 registers on I2C.
>
> It is true only for your particular platform where usb-c part is
> managed by firmware. Pinephone has the same anx7688 but linux will
> need a driver that manages usb-c in addition to DP.
>
> I'd suggest making it MFD driver from the beginning, or at least make
> proper bindings so we don't have to rework it and introduce binding
> incompatibilities in future.
>
Do you have example code on how the ANX7866 is used in pinephone?
There is a repo somewhere?
Thanks,
Enric
> > Signed-off-by: Nicolas Boichat
> > Signed-off-by: Hsin-Yi Wang
> > Signed-off-by: Enric Balletbo i Serra
> > ---
> >
> > Changes in v2:
> > - Move driver to drivers/gpu/drm/bridge/analogix.
> > - Make the driver OF only so we can reduce the ifdefs.
> > - Update the Copyright to 2020.
> > - Use probe_new so we can get rid of the i2c_device_id table.
> >
> > drivers/gpu/drm/bridge/analogix/Kconfig | 12 ++
> > drivers/gpu/drm/bridge/analogix/Makefile | 1 +
> > .../drm/bridge/analogix/analogix-anx7688.c| 188 ++
> > 3 files changed, 201 insertions(+)
> > create mode 100644 drivers/gpu/drm/bridge/analogix/analogix-anx7688.c
> >
> > diff --git a/drivers/gpu/drm/bridge/analogix/Kconfig
> > b/drivers/gpu/drm/bridge/analogix/Kconfig
> > index e1fa7d820373..af7c2939403c 100644
> > --- a/drivers/gpu/drm/bridge/analogix/Kconfig
> > +++ b/drivers/gpu/drm/bridge/analogix/Kconfig
> > @@ -11,6 +11,18 @@ config DRM_ANALOGIX_ANX6345
> > ANX6345 transforms the LVTTL RGB output of an
> > application processor to eDP or DisplayPort.
> >
> > +config DRM_ANALOGIX_ANX7688
> > + tristate "Analogix ANX7688 bridge"
> > + depends on OF
> > + select DRM_KMS_HELPER
> > + select REGMAP_I2C
> > + help
> > + ANX7688 is an ultra-low power 4k Ultra-HD (4096x2160p60)
> > + mobile HD transmitter designed for portable devices. The
> > + ANX7688 converts HDMI 2.0 to DisplayPort 1.3 Ultra-HD
> > + including an intelligent crosspoint switch to support
> > + USB Type-C.
> > +
> > config DRM_ANALOGIX_ANX78XX
> > tristate "Analogix ANX78XX bridge"
> > select DRM_ANALOGIX_DP
> > diff --git a/drivers/gpu/drm/bridge/analogix/Makefile
> > b/drivers/gpu/drm/bridge/analogix/Makefile
> > index 97669b374098..27cd73635c8c 100644
> > --- a/drivers/gpu/drm/bridge/analogix/Makefile
> > +++ b/drivers/gpu/drm/bridge/analogix/Makefile
> > @@ -1,5 +1,6 @@
> > # SPDX-License-Identifier: GPL-2.0-only
> > analogix_dp-objs := analogix_dp_core.o analogix_dp_reg.o
> > analogix-i2c-dptx.o
> > obj-$(CONFIG_DRM_ANALOGIX_ANX6345) += analogix-anx6345.o
> > +obj-$(CONFIG_DRM_ANALOGIX_ANX7688) += analogix-anx7688.o
> > obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
> > obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix_dp.o
> > diff --git a/drivers/gpu/drm/bridge/analogix/analogix-anx7688.c
> > b/drivers/gpu/drm/bridge/analogix/analogix-anx7688.c
> > new file mode 100644
> > index ..10a7cd0f9126
> > --- /dev/null
> > +++ b/drivers/gpu/drm/bridge/analogix/analogix-anx7688.c
> > @@ -0,0 +1,188 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +/*
> > + * ANX7688 HDMI->DP bridge driver
> > + *
> > + * Copyright 2020 Google LLC
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +/* Register addresses */
> > +#define VENDOR_ID_REG 0x00
> > +#define DEVICE_ID_REG 0x02
> > +
> > +#define FW_VERSION_REG 0x80
> > +
> > +#define DP_BANDWIDTH_REG 0x85
> > +#define DP_LANE_COUNT_REG 0x86
> > +
> > +#define VENDOR_ID 0x1f29
> > +#define DEVICE_ID 0x7688
> > +
> > +/* First supported firmware version (0.85) */
> > +#define MINIMUM_FW_VERSION 0x0085
> > +
> > +struct anx7688 {
> > + struct drm_bridge bridge;
> > + struct i2c_client *client;
> > + struct regmap *regmap;
> > +
> > + bool filter;
> > +};
> > +
> > +static inline struct anx7688 *bridge_to_anx7688(struct drm_bridge *bridge)
> > +{
> > + return container_of(bridge, struct anx7688, bridge);
> > +}
> > +
> > +static bool anx7688_bridge_mode_fixup(struct drm_bridge *bridge,
> > + const struct drm_display_mode *mode,
> > + struct drm_display_mode
> > *adjusted_mode)
> > +{
> > + struct anx7688 *anx7688 = bridge_to_anx7688(bridge);
> > + int totalbw, requiredbw;
> > + u8 dpbw, lanecount;
> > + u8
Re: [PATCH AUTOSEL 5.5 155/542] drm/amdkfd: remove set but not used variable 'top_dev'
On Fri, Feb 14, 2020 at 10:42:27AM -0500, Sasha Levin wrote:
> From: zhengbin
>
> [ Upstream commit d191bd678153307573d615bb42da4fcca19fe477 ]
>
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/gpu/drm/amd/amdkfd/kfd_iommu.c: In function kfd_iommu_device_init:
> drivers/gpu/drm/amd/amdkfd/kfd_iommu.c:65:30: warning: variable top_dev set
> but not used [-Wunused-but-set-variable]
>
> Reported-by: Hulk Robot
> Fixes: 1ae99eab34f9 ("drm/amdkfd: Initialize HSA_CAP_ATS_PRESENT capability
> in topology codes")
> Signed-off-by: zhengbin
> Reviewed-by: Felix Kuehling
> Signed-off-by: Felix Kuehling
> Signed-off-by: Alex Deucher
> Signed-off-by: Sasha Levin
> ---
> drivers/gpu/drm/amd/amdkfd/kfd_iommu.c | 3 ---
> 1 file changed, 3 deletions(-)
Unless all of these "unused bt set variable" patches are needed for
"real" fixes, there's no need to add them here as we are NOT building
the kernel with that option enabled any time soon from what I can tell.
So you can drop a ton of these patches from all of these AUTOSEL
branches please.
thanks,
greg kh
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 0/3] KVM: x86: honor guest memory type
On Fri, Feb 14, 2020 at 11:52 AM Sean Christopherson
wrote:
>
> On Fri, Feb 14, 2020 at 11:26:06AM +0100, Paolo Bonzini wrote:
> > On 13/02/20 23:18, Chia-I Wu wrote:
> > >
> > > The bug you mentioned was probably this one
> > >
> > > https://bugzilla.kernel.org/show_bug.cgi?id=104091
> >
> > Yes, indeed.
> >
> > > From what I can tell, the commit allowed the guests to create cached
> > > mappings to MMIO regions and caused MCEs. That is different than what
> > > I need, which is to allow guests to create uncached mappings to system
> > > ram (i.e., !kvm_is_mmio_pfn) when the host userspace also has uncached
> > > mappings. But it is true that this still allows the userspace & guest
> > > kernel to create conflicting memory types.
>
> This is ok.
>
> > Right, the question is whether the MCEs were tied to MMIO regions
> > specifically and if so why.
>
> 99.9% likelihood the answer is "yes". Cacheable accesses to non-existent
> memory and most (all?) MMIO regions will cause a #MC. This includes
> speculative accesses.
>
> Commit fd717f11015f ("KVM: x86: apply guest MTRR virtualization on host
> reserved pages") explicitly had a comment "1. MMIO: trust guest MTRR",
> which is basically a direct avenue to generating #MCs.
>
> IIRC, WC accesses to non-existent memory will also cause #MC, but KVM has
> bigger problems if it has PRESENT EPTEs pointing at garbage.
>
> > An interesting remark is in the footnote of table 11-7 in the SDM.
> > There, for the MTRR (EPT for us) memory type UC you can read:
> >
> > The UC attribute comes from the MTRRs and the processors are not
> > required to snoop their caches since the data could never have
> > been cached. This attribute is preferred for performance reasons.
> >
> > There are two possibilities:
> >
> > 1) the footnote doesn't apply to UC mode coming from EPT page tables.
> > That would make your change safe.
> >
> > 2) the footnote also applies when the UC attribute comes from the EPT
> > page tables rather than the MTRRs. In that case, the host should use
> > UC as the EPT page attribute if and only if it's consistent with the host
> > MTRRs; it would be more or less impossible to honor UC in the guest MTRRs.
> > In that case, something like the patch below would be needed.
>
> (2), the EPTs effectively replace the MTRRs. The expectation being that
> the VMM will use always use EPT memtypes consistent with the MTRRs.
This is my understanding as well.
> > It is not clear from the manual why the footnote would not apply to WC; that
> > is, the manual doesn't say explicitly that the processor does not do
> > snooping
> > for accesses to WC memory. But I guess that must be the case, which is why
> > I
> > used MTRR_TYPE_WRCOMB in the patch below.
>
> A few paragraphs below table 11-12 states:
>
> In particular, a WC page must never be aliased to a cacheable page because
> WC writes may not check the processor caches.
>
> > Either way, we would have an explanation of why creating cached mapping to
> > MMIO regions would, and why in practice we're not seeing MCEs for guest RAM
> > (the guest would have set WB for that memory in its MTRRs, not UC).
>
> Aliasing (physical) RAM with different memtypes won't cause #MC, just
> memory corruption.
What we need potentially gives the userspace (the guest kernel, to be
exact) the ability to create conflicting memory types. If we can be
sure that the worst scenario is for a guest to corrupt its own memory,
by only allowing aliases on physical ram, that seems alright.
AFAICT, it is currently allowed on ARM (verified) and AMD (not
verified, but svm_get_mt_mask returns 0 which supposedly means the NPT
does not restrict what the guest PAT can do). This diff would do the
trick for Intel without needing any uapi change:
diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
index e3394c839dea..88af11cc551a 100644
--- a/arch/x86/kvm/vmx/vmx.c
+++ b/arch/x86/kvm/vmx/vmx.c
@@ -6905,12 +6905,6 @@ static u64 vmx_get_mt_mask(struct kvm_vcpu
*vcpu, gfn_t gfn, bool is_mmio)
goto exit;
}
- if (!kvm_arch_has_noncoherent_dma(vcpu->kvm)) {
- ipat = VMX_EPT_IPAT_BIT;
- cache = MTRR_TYPE_WRBACK;
- goto exit;
- }
-
if (kvm_read_cr0(vcpu) & X86_CR0_CD) {
ipat = VMX_EPT_IPAT_BIT;
if (kvm_check_has_quirk(vcpu->kvm, KVM_X86_QUIRK_CD_NW_CLEARED))
> > One thing you didn't say: how would userspace use KVM_MEM_DMA? On which
> > regions would it be set?
> >
> > Thanks,
> >
> > Paolo
> >
> > diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
> > index dc331fb06495..2be6f7effa1d 100644
> > --- a/arch/x86/kvm/vmx/vmx.c
> > +++ b/arch/x86/kvm/vmx/vmx.c
> > @@ -6920,8 +6920,16 @@ static u64 vmx_get_mt_mask(struct kvm_vcpu *vcpu,
> > gfn_t gfn, bool is_mmio)
> > }
> >
> > cache = kvm_mtrr_get_guest_memory_type(vcpu, gfn);
> > -
> > exit:
> > + if (cache == MTRR_TYPE_UNCACHABLE &&
Re: [git pull] drm fixes for 5.6-rc2
The pull request you sent on Fri, 14 Feb 2020 14:15:53 +1000: > git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2020-02-14 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/3f0d329371c08dfa3227f1716e522f3a8a081155 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/3] drm/panel: simple: fix osd070t1718_19ts sync drive edge
Hi Tomi.
On Mon, Feb 10, 2020 at 10:15:33AM +0200, Tomi Valkeinen wrote:
> Hi Thierry,
>
> On 02/12/2019 15:07, Laurent Pinchart wrote:
> > Hi Tomi,
> >
> > Thank you for the patch.
> >
> > On Thu, Nov 14, 2019 at 11:39:50AM +0200, Tomi Valkeinen wrote:
> > > The panel datasheet says that the panel samples at falling edge, but
> > > does not say anything about h/v sync signals. Testing shows that if the
> > > sync signals are driven on falling edge, the picture on the panel will
> > > be slightly shifted right.
> > >
> > > Setting sync drive edge to the same as data drive edge fixes this issue.
> > >
> > > Signed-off-by: Tomi Valkeinen
> >
> > I don't have access to the documentation, but this makes sense, so
> >
> > Acked-by: Laurent Pinchart
> >
> > > ---
> > > drivers/gpu/drm/panel/panel-simple.c | 3 ++-
> > > 1 file changed, 2 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/panel/panel-simple.c
> > > b/drivers/gpu/drm/panel/panel-simple.c
> > > index 5d487686d25c..0784536ae6af 100644
> > > --- a/drivers/gpu/drm/panel/panel-simple.c
> > > +++ b/drivers/gpu/drm/panel/panel-simple.c
> > > @@ -2397,7 +2397,8 @@ static const struct panel_desc
> > > osddisplays_osd070t1718_19ts = {
> > > .height = 91,
> > > },
> > > .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
> > > - .bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE,
> > > + .bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE |
> > > + DRM_BUS_FLAG_SYNC_DRIVE_POSEDGE,
> > > .connector_type = DRM_MODE_CONNECTOR_DPI,
> > > };
>
> Can this be merged?
I have lost the original mail.
Can you re-send or provide a patchwork pointer or similar.
Then I will apply.
PS. Mail had been stuck in my spam quarantine so did not get it until
now.
Sam
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/2] drm/bridge: anx7688: Add anx7688 bridge driver support
On Thu, Feb 13, 2020 at 6:54 AM Enric Balletbo i Serra
wrote:
>
> From: Nicolas Boichat
>
> ANX7688 is a HDMI to DP converter (as well as USB-C port controller),
> that has an internal microcontroller.
>
> The only reason a Linux kernel driver is necessary is to reject
> resolutions that require more bandwidth than what is available on
> the DP side. DP bandwidth and lane count are reported by the bridge
> via 2 registers on I2C.
It is true only for your particular platform where usb-c part is
managed by firmware. Pinephone has the same anx7688 but linux will
need a driver that manages usb-c in addition to DP.
I'd suggest making it MFD driver from the beginning, or at least make
proper bindings so we don't have to rework it and introduce binding
incompatibilities in future.
> Signed-off-by: Nicolas Boichat
> Signed-off-by: Hsin-Yi Wang
> Signed-off-by: Enric Balletbo i Serra
> ---
>
> Changes in v2:
> - Move driver to drivers/gpu/drm/bridge/analogix.
> - Make the driver OF only so we can reduce the ifdefs.
> - Update the Copyright to 2020.
> - Use probe_new so we can get rid of the i2c_device_id table.
>
> drivers/gpu/drm/bridge/analogix/Kconfig | 12 ++
> drivers/gpu/drm/bridge/analogix/Makefile | 1 +
> .../drm/bridge/analogix/analogix-anx7688.c| 188 ++
> 3 files changed, 201 insertions(+)
> create mode 100644 drivers/gpu/drm/bridge/analogix/analogix-anx7688.c
>
> diff --git a/drivers/gpu/drm/bridge/analogix/Kconfig
> b/drivers/gpu/drm/bridge/analogix/Kconfig
> index e1fa7d820373..af7c2939403c 100644
> --- a/drivers/gpu/drm/bridge/analogix/Kconfig
> +++ b/drivers/gpu/drm/bridge/analogix/Kconfig
> @@ -11,6 +11,18 @@ config DRM_ANALOGIX_ANX6345
> ANX6345 transforms the LVTTL RGB output of an
> application processor to eDP or DisplayPort.
>
> +config DRM_ANALOGIX_ANX7688
> + tristate "Analogix ANX7688 bridge"
> + depends on OF
> + select DRM_KMS_HELPER
> + select REGMAP_I2C
> + help
> + ANX7688 is an ultra-low power 4k Ultra-HD (4096x2160p60)
> + mobile HD transmitter designed for portable devices. The
> + ANX7688 converts HDMI 2.0 to DisplayPort 1.3 Ultra-HD
> + including an intelligent crosspoint switch to support
> + USB Type-C.
> +
> config DRM_ANALOGIX_ANX78XX
> tristate "Analogix ANX78XX bridge"
> select DRM_ANALOGIX_DP
> diff --git a/drivers/gpu/drm/bridge/analogix/Makefile
> b/drivers/gpu/drm/bridge/analogix/Makefile
> index 97669b374098..27cd73635c8c 100644
> --- a/drivers/gpu/drm/bridge/analogix/Makefile
> +++ b/drivers/gpu/drm/bridge/analogix/Makefile
> @@ -1,5 +1,6 @@
> # SPDX-License-Identifier: GPL-2.0-only
> analogix_dp-objs := analogix_dp_core.o analogix_dp_reg.o analogix-i2c-dptx.o
> obj-$(CONFIG_DRM_ANALOGIX_ANX6345) += analogix-anx6345.o
> +obj-$(CONFIG_DRM_ANALOGIX_ANX7688) += analogix-anx7688.o
> obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
> obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix_dp.o
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix-anx7688.c
> b/drivers/gpu/drm/bridge/analogix/analogix-anx7688.c
> new file mode 100644
> index ..10a7cd0f9126
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/analogix/analogix-anx7688.c
> @@ -0,0 +1,188 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * ANX7688 HDMI->DP bridge driver
> + *
> + * Copyright 2020 Google LLC
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +
> +/* Register addresses */
> +#define VENDOR_ID_REG 0x00
> +#define DEVICE_ID_REG 0x02
> +
> +#define FW_VERSION_REG 0x80
> +
> +#define DP_BANDWIDTH_REG 0x85
> +#define DP_LANE_COUNT_REG 0x86
> +
> +#define VENDOR_ID 0x1f29
> +#define DEVICE_ID 0x7688
> +
> +/* First supported firmware version (0.85) */
> +#define MINIMUM_FW_VERSION 0x0085
> +
> +struct anx7688 {
> + struct drm_bridge bridge;
> + struct i2c_client *client;
> + struct regmap *regmap;
> +
> + bool filter;
> +};
> +
> +static inline struct anx7688 *bridge_to_anx7688(struct drm_bridge *bridge)
> +{
> + return container_of(bridge, struct anx7688, bridge);
> +}
> +
> +static bool anx7688_bridge_mode_fixup(struct drm_bridge *bridge,
> + const struct drm_display_mode *mode,
> + struct drm_display_mode *adjusted_mode)
> +{
> + struct anx7688 *anx7688 = bridge_to_anx7688(bridge);
> + int totalbw, requiredbw;
> + u8 dpbw, lanecount;
> + u8 regs[2];
> + int ret;
> +
> + if (!anx7688->filter)
> + return true;
> +
> + /* Read both regs 0x85 (bandwidth) and 0x86 (lane count). */
> + ret = regmap_bulk_read(anx7688->regmap, DP_BANDWIDTH_REG, regs, 2);
> + if (ret < 0) {
> + dev_err(>client->dev,
> + "Failed to read bandwidth/lane count\n");
> + return false;
> + }
> + dpbw = regs[0];
> +
Re: [RFC PATCH 0/3] KVM: x86: honor guest memory type
On Fri, Feb 14, 2020 at 2:26 AM Paolo Bonzini wrote:
>
> On 13/02/20 23:18, Chia-I Wu wrote:
> >
> > The bug you mentioned was probably this one
> >
> > https://bugzilla.kernel.org/show_bug.cgi?id=104091
>
> Yes, indeed.
>
> > From what I can tell, the commit allowed the guests to create cached
> > mappings to MMIO regions and caused MCEs. That is different than what
> > I need, which is to allow guests to create uncached mappings to system
> > ram (i.e., !kvm_is_mmio_pfn) when the host userspace also has uncached
> > mappings. But it is true that this still allows the userspace & guest
> > kernel to create conflicting memory types.
>
> Right, the question is whether the MCEs were tied to MMIO regions
> specifically and if so why.
>
> An interesting remark is in the footnote of table 11-7 in the SDM.
> There, for the MTRR (EPT for us) memory type UC you can read:
>
> The UC attribute comes from the MTRRs and the processors are not
> required to snoop their caches since the data could never have
> been cached. This attribute is preferred for performance reasons.
>
> There are two possibilities:
>
> 1) the footnote doesn't apply to UC mode coming from EPT page tables.
> That would make your change safe.
>
> 2) the footnote also applies when the UC attribute comes from the EPT
> page tables rather than the MTRRs. In that case, the host should use
> UC as the EPT page attribute if and only if it's consistent with the host
> MTRRs; it would be more or less impossible to honor UC in the guest MTRRs.
> In that case, something like the patch below would be needed.
>
> It is not clear from the manual why the footnote would not apply to WC; that
> is, the manual doesn't say explicitly that the processor does not do snooping
> for accesses to WC memory. But I guess that must be the case, which is why I
> used MTRR_TYPE_WRCOMB in the patch below.
>
> Either way, we would have an explanation of why creating cached mapping to
> MMIO regions would, and why in practice we're not seeing MCEs for guest RAM
> (the guest would have set WB for that memory in its MTRRs, not UC).
>
> One thing you didn't say: how would userspace use KVM_MEM_DMA? On which
> regions would it be set?
It will be set for shmems that are mapped WC.
GPU/DRM drivers allocate shmems as DMA-able gpu buffers and allow the
userspace to map them cached or WC (I915_MMAP_WC or
AMDGPU_GEM_CREATE_CPU_GTT_USWC for example). When a shmem is mapped
WC and is made available to the guest, we would like the ability to
map the region WC in the guest.
> Thanks,
>
> Paolo
>
> diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
> index dc331fb06495..2be6f7effa1d 100644
> --- a/arch/x86/kvm/vmx/vmx.c
> +++ b/arch/x86/kvm/vmx/vmx.c
> @@ -6920,8 +6920,16 @@ static u64 vmx_get_mt_mask(struct kvm_vcpu *vcpu,
> gfn_t gfn, bool is_mmio)
> }
>
> cache = kvm_mtrr_get_guest_memory_type(vcpu, gfn);
> -
> exit:
> + if (cache == MTRR_TYPE_UNCACHABLE && !is_mmio) {
> + /*
> +* We cannot set UC in the EPT page tables as it can cause
> +* machine check exceptions (??). Hopefully the guest is
> +* using PAT.
> +*/
> + cache = MTRR_TYPE_WRCOMB;
> + }
> +
> return (cache << VMX_EPT_MT_EPTE_SHIFT) | ipat;
> }
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 09/11] drm, cgroup: Introduce lgpu as DRM cgroup resource
On Fri, Feb 14, 2020 at 03:28:40PM -0500, Kenny Ho wrote: > Can you elaborate, per your understanding, how the lgpu weight > attribute differ from the io.weight you suggested? Is it merely a Oh, it's the non-weight part which is problematic. > formatting/naming issue or is it the implementation details that you > find troubling? From my perspective, the weight attribute implements > as you suggested back in RFCv4 (proportional control on top of a unit > - either physical or time unit.) > > Perhaps more explicit questions would help me understand what you > mean. If I remove the 'list' and 'count' attributes leaving just > weight, is that satisfactory? Are you saying the idea of affinity or At least from interface pov, yes, although I think it should be clear what the weight controls. > named-resource is banned from cgroup entirely (even though it exists > in the form of cpuset already and users are interested in having such > options [i.e. userspace OpenCL] when needed?) > > To be clear, I am not saying no proportional control. I am saying > give the user the options, which is what has been implemented. We can get there if we *really* have to but not from the get-go but I'd rather avoid affinities if at all possible. Thanks. -- tejun ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 09/11] drm, cgroup: Introduce lgpu as DRM cgroup resource
Hi Tejun, On Fri, Feb 14, 2020 at 2:17 PM Tejun Heo wrote: > > I have to agree with Daniel here. My apologies if I weren't clear > enough. Here's one interface I can think of: > > * compute weight: The same format as io.weight. Proportional control >of gpu compute. > > * memory low: Please see how the system memory.low behaves. For gpus, >it'll need per-device entries. > > Note that for both, there one number to configure and conceptually > it's pretty clear to everybody what that number means, which is not to > say that it's clear to implement but it's much better to deal with > that on this side of the interface than the other. Can you elaborate, per your understanding, how the lgpu weight attribute differ from the io.weight you suggested? Is it merely a formatting/naming issue or is it the implementation details that you find troubling? From my perspective, the weight attribute implements as you suggested back in RFCv4 (proportional control on top of a unit - either physical or time unit.) Perhaps more explicit questions would help me understand what you mean. If I remove the 'list' and 'count' attributes leaving just weight, is that satisfactory? Are you saying the idea of affinity or named-resource is banned from cgroup entirely (even though it exists in the form of cpuset already and users are interested in having such options [i.e. userspace OpenCL] when needed?) To be clear, I am not saying no proportional control. I am saying give the user the options, which is what has been implemented. > cc'ing Johannes. Do you have anything on mind regarding how gpu memory > configuration should look like? e.g. should it go w/ weights rather > than absoulte units (I don't think so given that it'll most likely > need limits at some point too but still and there are benefits from > staying consistent with system memory). > > Also, a rather trivial high level question. Is drm a good controller > name given that other controller names are like cpu, memory, io? There was a discussion about naming early in the RFC (I believe RFCv2), the consensuses then was to use drmcg to align with the drm subsystem. I have no problem renaming it to gpucg or something similar if that is the last thing that's blocking acceptance. For now, I would like to get some clarity on the implementation before having more code churn. Regards, Kenny > Thanks. > > -- > tejun ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 13/15] drm/amdgpu/display: split dp connector registration (v3)
On Fri, Feb 14, 2020 at 1:35 PM Daniel Vetter wrote:
>
> On Fri, Feb 14, 2020 at 12:39:22PM -0500, Alex Deucher wrote:
> > On Fri, Feb 14, 2020 at 2:39 AM Daniel Vetter wrote:
> > >
> > > On Fri, Feb 07, 2020 at 04:17:13PM -0500, Alex Deucher wrote:
> > > > Split into init and register functions to avoid a segfault
> > > > in some configs when the load/unload callbacks are removed.
> > > >
> > > > v2:
> > > > - add back accidently dropped has_aux setting
> > > > - set dev in late_register
> > > >
> > > > v3:
> > > > - fix dp cec ordering
> > >
> > > Why did you move this back out of the late_register callback when going
> > > from v2->v3? In i915 we register the cec stuff from ->late_register, like
> >
> > I got a bunch of complaints from the cec code when I had it switched
> > the other way. They went away when I moved it back. I don't remember
> > the exact messages off hand.
>
> Would be interesting to learn want went wrong, just in case there's a core
> bug here somewhere that prevents drivers from tdtr. But definitely no
> reason to hold off this patch.
I'll repo it next week and send it out for posterity. Thanks for the review.
Alex
> -Daniel
>
> >
> > Alex
> >
> > > anything else userspace visible. Maybe follow-up patch (the idea behind
> > > removing the ->load callback is to close all the driver load races,
> > > instead of only open("/dev/dri/0"), which is protected by
> > > drm_global_mutex). On this:
> > >
> > > Reviewed-by: Daniel Vetter
> > >
> > > Cheers, Daniel
> > >
> > > >
> > > > Signed-off-by: Alex Deucher
> > > > ---
> > > > drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 16
> > > > drivers/gpu/drm/amd/amdgpu/atombios_dp.c | 10 ++
> > > > .../amd/display/amdgpu_dm/amdgpu_dm_mst_types.c | 7 ++-
> > > > 3 files changed, 24 insertions(+), 9 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> > > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> > > > index ec1501e3a63a..f355d9a752d2 100644
> > > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> > > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> > > > @@ -1461,6 +1461,20 @@ static enum drm_mode_status
> > > > amdgpu_connector_dp_mode_valid(struct drm_connector
> > > > return MODE_OK;
> > > > }
> > > >
> > > > +static int
> > > > +amdgpu_connector_late_register(struct drm_connector *connector)
> > > > +{
> > > > + struct amdgpu_connector *amdgpu_connector =
> > > > to_amdgpu_connector(connector);
> > > > + int r = 0;
> > > > +
> > > > + if (amdgpu_connector->ddc_bus->has_aux) {
> > > > + amdgpu_connector->ddc_bus->aux.dev =
> > > > amdgpu_connector->base.kdev;
> > > > + r = drm_dp_aux_register(_connector->ddc_bus->aux);
> > > > + }
> > > > +
> > > > + return r;
> > > > +}
> > > > +
> > > > static const struct drm_connector_helper_funcs
> > > > amdgpu_connector_dp_helper_funcs = {
> > > > .get_modes = amdgpu_connector_dp_get_modes,
> > > > .mode_valid = amdgpu_connector_dp_mode_valid,
> > > > @@ -1475,6 +1489,7 @@ static const struct drm_connector_funcs
> > > > amdgpu_connector_dp_funcs = {
> > > > .early_unregister = amdgpu_connector_unregister,
> > > > .destroy = amdgpu_connector_destroy,
> > > > .force = amdgpu_connector_dvi_force,
> > > > + .late_register = amdgpu_connector_late_register,
> > > > };
> > > >
> > > > static const struct drm_connector_funcs amdgpu_connector_edp_funcs = {
> > > > @@ -1485,6 +1500,7 @@ static const struct drm_connector_funcs
> > > > amdgpu_connector_edp_funcs = {
> > > > .early_unregister = amdgpu_connector_unregister,
> > > > .destroy = amdgpu_connector_destroy,
> > > > .force = amdgpu_connector_dvi_force,
> > > > + .late_register = amdgpu_connector_late_register,
> > > > };
> > > >
> > > > void
> > > > diff --git a/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
> > > > b/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
> > > > index ea702a64f807..9b74cfdba7b8 100644
> > > > --- a/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
> > > > +++ b/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
> > > > @@ -186,16 +186,10 @@ amdgpu_atombios_dp_aux_transfer(struct drm_dp_aux
> > > > *aux, struct drm_dp_aux_msg *m
> > > >
> > > > void amdgpu_atombios_dp_aux_init(struct amdgpu_connector
> > > > *amdgpu_connector)
> > > > {
> > > > - int ret;
> > > > -
> > > > amdgpu_connector->ddc_bus->rec.hpd = amdgpu_connector->hpd.hpd;
> > > > - amdgpu_connector->ddc_bus->aux.dev = amdgpu_connector->base.kdev;
> > > > amdgpu_connector->ddc_bus->aux.transfer =
> > > > amdgpu_atombios_dp_aux_transfer;
> > > > - ret = drm_dp_aux_register(_connector->ddc_bus->aux);
> > > > - if (!ret)
> > > > - amdgpu_connector->ddc_bus->has_aux = true;
> > > > -
> > > > - WARN(ret, "drm_dp_aux_register_i2c_bus() failed with error %d\n",
> > > > ret);
> > > > +
Re: [RFC PATCH 0/3] KVM: x86: honor guest memory type
On Fri, Feb 14, 2020 at 11:26:06AM +0100, Paolo Bonzini wrote:
> On 13/02/20 23:18, Chia-I Wu wrote:
> >
> > The bug you mentioned was probably this one
> >
> > https://bugzilla.kernel.org/show_bug.cgi?id=104091
>
> Yes, indeed.
>
> > From what I can tell, the commit allowed the guests to create cached
> > mappings to MMIO regions and caused MCEs. That is different than what
> > I need, which is to allow guests to create uncached mappings to system
> > ram (i.e., !kvm_is_mmio_pfn) when the host userspace also has uncached
> > mappings. But it is true that this still allows the userspace & guest
> > kernel to create conflicting memory types.
This is ok.
> Right, the question is whether the MCEs were tied to MMIO regions
> specifically and if so why.
99.9% likelihood the answer is "yes". Cacheable accesses to non-existent
memory and most (all?) MMIO regions will cause a #MC. This includes
speculative accesses.
Commit fd717f11015f ("KVM: x86: apply guest MTRR virtualization on host
reserved pages") explicitly had a comment "1. MMIO: trust guest MTRR",
which is basically a direct avenue to generating #MCs.
IIRC, WC accesses to non-existent memory will also cause #MC, but KVM has
bigger problems if it has PRESENT EPTEs pointing at garbage.
> An interesting remark is in the footnote of table 11-7 in the SDM.
> There, for the MTRR (EPT for us) memory type UC you can read:
>
> The UC attribute comes from the MTRRs and the processors are not
> required to snoop their caches since the data could never have
> been cached. This attribute is preferred for performance reasons.
>
> There are two possibilities:
>
> 1) the footnote doesn't apply to UC mode coming from EPT page tables.
> That would make your change safe.
>
> 2) the footnote also applies when the UC attribute comes from the EPT
> page tables rather than the MTRRs. In that case, the host should use
> UC as the EPT page attribute if and only if it's consistent with the host
> MTRRs; it would be more or less impossible to honor UC in the guest MTRRs.
> In that case, something like the patch below would be needed.
(2), the EPTs effectively replace the MTRRs. The expectation being that
the VMM will use always use EPT memtypes consistent with the MTRRs.
> It is not clear from the manual why the footnote would not apply to WC; that
> is, the manual doesn't say explicitly that the processor does not do snooping
> for accesses to WC memory. But I guess that must be the case, which is why I
> used MTRR_TYPE_WRCOMB in the patch below.
A few paragraphs below table 11-12 states:
In particular, a WC page must never be aliased to a cacheable page because
WC writes may not check the processor caches.
> Either way, we would have an explanation of why creating cached mapping to
> MMIO regions would, and why in practice we're not seeing MCEs for guest RAM
> (the guest would have set WB for that memory in its MTRRs, not UC).
Aliasing (physical) RAM with different memtypes won't cause #MC, just
memory corruption.
> One thing you didn't say: how would userspace use KVM_MEM_DMA? On which
> regions would it be set?
>
> Thanks,
>
> Paolo
>
> diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
> index dc331fb06495..2be6f7effa1d 100644
> --- a/arch/x86/kvm/vmx/vmx.c
> +++ b/arch/x86/kvm/vmx/vmx.c
> @@ -6920,8 +6920,16 @@ static u64 vmx_get_mt_mask(struct kvm_vcpu *vcpu,
> gfn_t gfn, bool is_mmio)
> }
>
> cache = kvm_mtrr_get_guest_memory_type(vcpu, gfn);
> -
> exit:
> + if (cache == MTRR_TYPE_UNCACHABLE && !is_mmio) {
> + /*
> + * We cannot set UC in the EPT page tables as it can cause
> + * machine check exceptions (??). Hopefully the guest is
> + * using PAT.
> + */
> + cache = MTRR_TYPE_WRCOMB;
This is unnecessary. Setting UC in the EPT tables will never directly lead
to #MC. Forcing WC is likely more dangerous.
> + }
> +
> return (cache << VMX_EPT_MT_EPTE_SHIFT) | ipat;
> }
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 0/6] drm/virtio: rework batching
Series is Reviewed-by: Chia-I Wu Thanks! On Fri, Feb 14, 2020 at 4:55 AM Gerd Hoffmann wrote: > > v4: > - add patches #2 + #6. > v3: > - split into multiple patches. > > Gerd Hoffmann (6): > drm/virtio: rework notification for better batching > drm/virtio: notify before waiting > drm/virtio: batch plane updates (pageflip) > drm/virtio: batch resource creation > drm/virtio: batch display query > drm/virtio: move remaining virtio_gpu_notify calls > > drivers/gpu/drm/virtio/virtgpu_drv.h | 6 ++--- > drivers/gpu/drm/virtio/virtgpu_display.c | 2 ++ > drivers/gpu/drm/virtio/virtgpu_gem.c | 2 ++ > drivers/gpu/drm/virtio/virtgpu_ioctl.c | 4 +++ > drivers/gpu/drm/virtio/virtgpu_kms.c | 5 > drivers/gpu/drm/virtio/virtgpu_object.c | 2 ++ > drivers/gpu/drm/virtio/virtgpu_plane.c | 7 +++-- > drivers/gpu/drm/virtio/virtgpu_vq.c | 33 ++-- > 8 files changed, 34 insertions(+), 27 deletions(-) > > -- > 2.18.2 > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/5] drm/virtio: track whether or not a context has been initiated
On Thu, Feb 13, 2020 at 3:18 PM Gurchetan Singh
wrote:
>
> Use an atomic variable to track whether a context has been
> initiated.
>
> v2: Fix possible race (@olv)
>
> Signed-off-by: Gurchetan Singh
> ---
> drivers/gpu/drm/virtio/virtgpu_drv.h | 1 +
> drivers/gpu/drm/virtio/virtgpu_ioctl.c | 3 +++
> drivers/gpu/drm/virtio/virtgpu_kms.c | 1 +
> 3 files changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h
> b/drivers/gpu/drm/virtio/virtgpu_drv.h
> index 72c1d9b59dfe..ca505984f8ab 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_drv.h
> +++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
> @@ -209,6 +209,7 @@ struct virtio_gpu_device {
>
> struct virtio_gpu_fpriv {
> uint32_t ctx_id;
> + atomic_t context_initiated;
> };
>
> /* virtio_ioctl.c */
> diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
> b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
> index 896c3f419a6d..a98884462944 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
> @@ -44,6 +44,9 @@ void virtio_gpu_create_context(struct drm_device *dev,
> if (!vgdev->has_virgl_3d)
> return;
>
> + if (!atomic_add_unless(>context_initiated, 1, 1))
> + return;
> +
How does this work? When thread A and B enter this function at the
same time, and thread B returns early, it is possible that thread B
queues other commands before thread A has the chance to queue
virtio_gpu_cmd_context_create.
> get_task_comm(dbgname, current);
> virtio_gpu_cmd_context_create(vgdev, vfpriv->ctx_id,
> strlen(dbgname), dbgname);
> diff --git a/drivers/gpu/drm/virtio/virtgpu_kms.c
> b/drivers/gpu/drm/virtio/virtgpu_kms.c
> index 282558576527..25248bad3fc4 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_kms.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_kms.c
> @@ -263,6 +263,7 @@ int virtio_gpu_driver_open(struct drm_device *dev, struct
> drm_file *file)
> }
>
> vfpriv->ctx_id = handle + 1;
> + atomic_set(>context_initiated, 0);
> file->driver_priv = vfpriv;
> virtio_gpu_create_context(dev, file);
> return 0;
> --
> 2.25.0.265.gbab2e86ba0-goog
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 09/11] drm, cgroup: Introduce lgpu as DRM cgroup resource
Hello, Kenny, Daniel. (cc'ing Johannes) On Fri, Feb 14, 2020 at 01:51:32PM -0500, Kenny Ho wrote: > On Fri, Feb 14, 2020 at 1:34 PM Daniel Vetter wrote: > > > > I think guidance from Tejun in previos discussions was pretty clear that > > he expects cgroups to be both a) standardized and c) sufficient clear > > meaning that end-users have a clear understanding of what happens when > > they change the resource allocation. > > > > I'm not sure lgpu here, at least as specified, passes either. > > I disagree (at least on the characterization of the feedback > provided.) I believe this series satisfied the sprite of Tejun's > guidance so far (the weight knob for lgpu, for example, was > specifically implemented base on his input.) But, I will let Tejun > speak for himself after he considered the implementation in detail. I have to agree with Daniel here. My apologies if I weren't clear enough. Here's one interface I can think of: * compute weight: The same format as io.weight. Proportional control of gpu compute. * memory low: Please see how the system memory.low behaves. For gpus, it'll need per-device entries. Note that for both, there one number to configure and conceptually it's pretty clear to everybody what that number means, which is not to say that it's clear to implement but it's much better to deal with that on this side of the interface than the other. cc'ing Johannes. Do you have anything on mind regarding how gpu memory configuration should look like? e.g. should it go w/ weights rather than absoulte units (I don't think so given that it'll most likely need limits at some point too but still and there are benefits from staying consistent with system memory). Also, a rather trivial high level question. Is drm a good controller name given that other controller names are like cpu, memory, io? Thanks. -- tejun ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 09/11] drm, cgroup: Introduce lgpu as DRM cgroup resource
On Fri, Feb 14, 2020 at 1:34 PM Daniel Vetter wrote: > > I think guidance from Tejun in previos discussions was pretty clear that > he expects cgroups to be both a) standardized and c) sufficient clear > meaning that end-users have a clear understanding of what happens when > they change the resource allocation. > > I'm not sure lgpu here, at least as specified, passes either. I disagree (at least on the characterization of the feedback provided.) I believe this series satisfied the sprite of Tejun's guidance so far (the weight knob for lgpu, for example, was specifically implemented base on his input.) But, I will let Tejun speak for himself after he considered the implementation in detail. Regards, Kenny > But I also > don't have much clue, so pulled Jason in - he understands how this all > gets reflected to userspace apis a lot better than me. > -Daniel > > > > > > > If it's carving up compute power, what's actually being carved up? Time? > > > Execution units/waves/threads? Even if that's the case, what advantage > > > does it give to have it in terms of a fixed set of lgpus where each > > > cgroup gets to pick a fixed set. Does affinity matter that much? Why > > > not just say how many waves the GPU supports and that they have to be > > > allocated in chunks of 16 waves (pulling a number out of thin air) and > > > let the cgroup specify how many waves it wants. > > > > > > Don't get me wrong here. I'm all for the notion of being able to use > > > cgroups to carve up GPU compute resources. However, this sounds to me > > > like the most AMD-specific solution possible. We (Intel) could probably > > > do some sort of carving up as well but we'd likely want to do it with > > > preemption and time-slicing rather than handing out specific EUs. > > > > This has been discussed in the RFC before > > (https://www.spinics.net/lists/cgroups/msg23469.html.) As mentioned > > before, the idea of a compute unit is hardly an AMD specific thing as > > it is in the OpenCL standard and part of the architecture of many > > different vendors. In addition, the interface presented here supports > > Intel's use case. What you described is what I considered as the > > "anonymous resources" view of the lgpu. What you/Intel can do, is to > > register your device to drmcg to have 100 lgpu and users can specify > > simply by count. So if they want to allocate 5% for a cgroup, they > > would set count=5. Per the documentation in this patch: "Some DRM > > devices may only support lgpu as anonymous resources. In such case, > > the significance of the position of the set bits in list will be > > ignored." What Intel does with the user expressed configuration of "5 > > out of 100" is entirely up to Intel (time slice if you like, change to > > specific EUs later if you like, or make it driver configurable to > > support both if you like.) > > > > Regards, > > Kenny > > > > > > > > On Fri, Feb 14, 2020 at 9:57 AM Kenny Ho wrote: > > >> > > >> drm.lgpu > > >> A read-write nested-keyed file which exists on all cgroups. > > >> Each entry is keyed by the DRM device's major:minor. > > >> > > >> lgpu stands for logical GPU, it is an abstraction used to > > >> subdivide a physical DRM device for the purpose of resource > > >> management. This file stores user configuration while the > > >> drm.lgpu.effective reflects the actual allocation after > > >> considering the relationship between the cgroups and their > > >> configurations. > > >> > > >> The lgpu is a discrete quantity that is device specific (i.e. > > >> some DRM devices may have 64 lgpus while others may have 100 > > >> lgpus.) The lgpu is a single quantity that can be allocated > > >> in three different ways denoted by the following nested keys. > > >> > > >> = == > > >> weightAllocate by proportion in relationship with > > >> active sibling cgroups > > >> count Allocate by amount statically, treat lgpu as > > >> anonymous resources > > >> list Allocate statically, treat lgpu as named > > >> resource > > >> = == > > >> > > >> For example: > > >> 226:0 weight=100 count=256 list=0-255 > > >> 226:1 weight=100 count=4 list=0,2,4,6 > > >> 226:2 weight=100 count=32 list=32-63 > > >> 226:3 weight=100 count=0 list= > > >> 226:4 weight=500 count=0 list= > > >> > > >> lgpu is represented by a bitmap and uses the bitmap_parselist > > >> kernel function so the list key input format is a > > >> comma-separated list of decimal numbers and ranges. > > >> > > >> Consecutively set bits are shown as two hyphen-separated decimal > > >> numbers, the smallest and largest bit numbers set in the range. > > >> Optionally
Re: [v2] arm64: dts: sc7180: add dsi controller and phy entries for idp dts
On Tue, Feb 11, 2020 at 05:07:35PM +0530, Harigovindan P wrote:
> subject: arm64: dts: sc7180: add dsi controller and phy entries for idp dts
nit: 'dts' at the end is redundant, the prefixes make it clear that this
is about DT entries.
Also the message isn't really concise. The main entries for the DSI
controller and the PHY are in sc7180.dtsi. I would suggest to drop
any mentions of DSI controller and PHYs, and just say something like
'Add nodes for IDP display'. In the body you could mention that the
display is the Visionox RM69299.
> Adding dsi controller and phy entries for idp dt.
>
> Signed-off-by: Harigovindan P
> ---
>
> Changes in v1:
> - Added dsi controller and dsi phy entries for idp dts
Changes in v1 is pointless, it's the first patch
> Changes in v2:
> - Adding dependency patchwork series
> - Removing suspend configuration
> - Adding blank before curly brace
>
> This patch depends on following patchwork series:
>
> https://patchwork.kernel.org/patch/11364687/
> https://patchwork.kernel.org/patch/11366303/
>
> arch/arm64/boot/dts/qcom/sc7180-idp.dts | 55 +
> 1 file changed, 55 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/sc7180-idp.dts
> b/arch/arm64/boot/dts/qcom/sc7180-idp.dts
> index 388f50ad4fde..6ccf8c3603ab 100644
> --- a/arch/arm64/boot/dts/qcom/sc7180-idp.dts
> +++ b/arch/arm64/boot/dts/qcom/sc7180-idp.dts
> @@ -7,6 +7,7 @@
>
> /dts-v1/;
>
> +#include
> #include
> #include "sc7180.dtsi"
> #include "pm6150.dtsi"
> @@ -232,6 +233,49 @@ vreg_bob: bob {
> };
> };
>
> + {
> + status = "okay";
> +
> + vdda-supply = <_l3c_1p2>;
> +
> + panel@0 {
> + compatible = "visionox,rm69299-1080p-display";
> + reg = <0>;
> +
> + vdda-supply = <_l8c_1p8>;
> + vdd3p3-supply = <_l18a_2p8>;
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <_pins>;
> +
> + reset-gpios = <_gpio 3 GPIO_ACTIVE_HIGH>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + port@0 {
> + reg = <0>;
> + panel0_in: endpoint {
> + remote-endpoint = <_out>;
> + };
> + };
> + };
> + };
> +
> + ports {
> + port@1 {
> + endpoint {
> + remote-endpoint = <_in>;
> + data-lanes = <0 1 2 3>;
> + };
> + };
> + };
> +};
> +
> +_phy {
> + status = "okay";
> +};
> +
> {
> status = "okay";
> pinctrl-names = "default";
> @@ -289,6 +333,17 @@ _1_qmpphy {
>
> /* PINCTRL - additions to nodes defined in sc7180.dtsi */
>
> +_gpio {
> + disp_pins: disp-pins {
> + pins = "gpio3";
> + function = "func1";
> + qcom,drive-strength = <2>;
> + power-source = <0>;
> + bias-disable;
> + output-low;
> + };
> +};
> +
> _clk {
> pinconf {
> pins = "gpio63";
To get the display actually to work you also need this:
diff --git a/arch/arm64/boot/dts/qcom/sc7180-idp.dts
b/arch/arm64/boot/dts/qcom/sc7180-idp.dts
index 88919da1510b03..fdbcb56dfa81f9 100644
--- a/arch/arm64/boot/dts/qcom/sc7180-idp.dts
+++ b/arch/arm64/boot/dts/qcom/sc7180-idp.dts
@@ -276,6 +276,14 @@
status = "okay";
};
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
+
{
status = "okay";
pinctrl-names = "default";
Maybe just add this to this patch?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/msm/a5xx: Always set an OPP supported hardware value
If the opp table specifies opp-supported-hw as a property but the driver
has not set a supported hardware value the OPP subsystem will reject
all the table entries.
Set a "default" value that will match the default table entries but not
conflict with any possible real bin values. Also fix a small memory leak
and free the buffer allocated by nvmem_cell_read().
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 27 ---
1 file changed, 20 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
index 7d9e63e..724024a 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
@@ -1446,18 +1446,31 @@ static const struct adreno_gpu_funcs funcs = {
static void check_speed_bin(struct device *dev)
{
struct nvmem_cell *cell;
- u32 bin, val;
+ u32 val;
+
+ /*
+* If the OPP table specifies a opp-supported-hw property then we have
+* to set something with dev_pm_opp_set_supported_hw() or the table
+* doesn't get populated so pick an arbitrary value that should
+* ensure the default frequencies are selected but not conflict with any
+* actual bins
+*/
+ val = 0x80;
cell = nvmem_cell_get(dev, "speed_bin");
- /* If a nvmem cell isn't defined, nothing to do */
- if (IS_ERR(cell))
- return;
+ if (!IS_ERR(cell)) {
+ void *buf = nvmem_cell_read(cell, NULL);
+
+ if (!IS_ERR(buf)) {
+ u8 bin = *((u8 *) buf);
- bin = *((u32 *) nvmem_cell_read(cell, NULL));
- nvmem_cell_put(cell);
+ val = (1 << bin);
+ kfree(buf);
+ }
- val = (1 << bin);
+ nvmem_cell_put(cell);
+ }
dev_pm_opp_set_supported_hw(dev, , 1);
}
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 13/15] drm/amdgpu/display: split dp connector registration (v3)
On Fri, Feb 14, 2020 at 12:39:22PM -0500, Alex Deucher wrote:
> On Fri, Feb 14, 2020 at 2:39 AM Daniel Vetter wrote:
> >
> > On Fri, Feb 07, 2020 at 04:17:13PM -0500, Alex Deucher wrote:
> > > Split into init and register functions to avoid a segfault
> > > in some configs when the load/unload callbacks are removed.
> > >
> > > v2:
> > > - add back accidently dropped has_aux setting
> > > - set dev in late_register
> > >
> > > v3:
> > > - fix dp cec ordering
> >
> > Why did you move this back out of the late_register callback when going
> > from v2->v3? In i915 we register the cec stuff from ->late_register, like
>
> I got a bunch of complaints from the cec code when I had it switched
> the other way. They went away when I moved it back. I don't remember
> the exact messages off hand.
Would be interesting to learn want went wrong, just in case there's a core
bug here somewhere that prevents drivers from tdtr. But definitely no
reason to hold off this patch.
-Daniel
>
> Alex
>
> > anything else userspace visible. Maybe follow-up patch (the idea behind
> > removing the ->load callback is to close all the driver load races,
> > instead of only open("/dev/dri/0"), which is protected by
> > drm_global_mutex). On this:
> >
> > Reviewed-by: Daniel Vetter
> >
> > Cheers, Daniel
> >
> > >
> > > Signed-off-by: Alex Deucher
> > > ---
> > > drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 16
> > > drivers/gpu/drm/amd/amdgpu/atombios_dp.c | 10 ++
> > > .../amd/display/amdgpu_dm/amdgpu_dm_mst_types.c | 7 ++-
> > > 3 files changed, 24 insertions(+), 9 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> > > index ec1501e3a63a..f355d9a752d2 100644
> > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> > > @@ -1461,6 +1461,20 @@ static enum drm_mode_status
> > > amdgpu_connector_dp_mode_valid(struct drm_connector
> > > return MODE_OK;
> > > }
> > >
> > > +static int
> > > +amdgpu_connector_late_register(struct drm_connector *connector)
> > > +{
> > > + struct amdgpu_connector *amdgpu_connector =
> > > to_amdgpu_connector(connector);
> > > + int r = 0;
> > > +
> > > + if (amdgpu_connector->ddc_bus->has_aux) {
> > > + amdgpu_connector->ddc_bus->aux.dev =
> > > amdgpu_connector->base.kdev;
> > > + r = drm_dp_aux_register(_connector->ddc_bus->aux);
> > > + }
> > > +
> > > + return r;
> > > +}
> > > +
> > > static const struct drm_connector_helper_funcs
> > > amdgpu_connector_dp_helper_funcs = {
> > > .get_modes = amdgpu_connector_dp_get_modes,
> > > .mode_valid = amdgpu_connector_dp_mode_valid,
> > > @@ -1475,6 +1489,7 @@ static const struct drm_connector_funcs
> > > amdgpu_connector_dp_funcs = {
> > > .early_unregister = amdgpu_connector_unregister,
> > > .destroy = amdgpu_connector_destroy,
> > > .force = amdgpu_connector_dvi_force,
> > > + .late_register = amdgpu_connector_late_register,
> > > };
> > >
> > > static const struct drm_connector_funcs amdgpu_connector_edp_funcs = {
> > > @@ -1485,6 +1500,7 @@ static const struct drm_connector_funcs
> > > amdgpu_connector_edp_funcs = {
> > > .early_unregister = amdgpu_connector_unregister,
> > > .destroy = amdgpu_connector_destroy,
> > > .force = amdgpu_connector_dvi_force,
> > > + .late_register = amdgpu_connector_late_register,
> > > };
> > >
> > > void
> > > diff --git a/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
> > > b/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
> > > index ea702a64f807..9b74cfdba7b8 100644
> > > --- a/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
> > > +++ b/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
> > > @@ -186,16 +186,10 @@ amdgpu_atombios_dp_aux_transfer(struct drm_dp_aux
> > > *aux, struct drm_dp_aux_msg *m
> > >
> > > void amdgpu_atombios_dp_aux_init(struct amdgpu_connector
> > > *amdgpu_connector)
> > > {
> > > - int ret;
> > > -
> > > amdgpu_connector->ddc_bus->rec.hpd = amdgpu_connector->hpd.hpd;
> > > - amdgpu_connector->ddc_bus->aux.dev = amdgpu_connector->base.kdev;
> > > amdgpu_connector->ddc_bus->aux.transfer =
> > > amdgpu_atombios_dp_aux_transfer;
> > > - ret = drm_dp_aux_register(_connector->ddc_bus->aux);
> > > - if (!ret)
> > > - amdgpu_connector->ddc_bus->has_aux = true;
> > > -
> > > - WARN(ret, "drm_dp_aux_register_i2c_bus() failed with error %d\n",
> > > ret);
> > > + drm_dp_aux_init(_connector->ddc_bus->aux);
> > > + amdgpu_connector->ddc_bus->has_aux = true;
> > > }
> > >
> > > /* general DP utility functions */
> > > diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> > > b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> > > index 3959c942c88b..d5b9e72f2649 100644
> > > ---
Re: [PATCH 09/11] drm, cgroup: Introduce lgpu as DRM cgroup resource
On Fri, Feb 14, 2020 at 12:08:35PM -0500, Kenny Ho wrote: > Hi Jason, > > Thanks for the review. > > On Fri, Feb 14, 2020 at 11:44 AM Jason Ekstrand wrote: > > > > Pardon my ignorance but I'm a bit confused by this. What is a "logical > > GPU"? What are we subdividing? Are we carving up memory? Compute power? > > Both? > > The intention is compute but it is up to the individual drm driver to decide. I think guidance from Tejun in previos discussions was pretty clear that he expects cgroups to be both a) standardized and c) sufficient clear meaning that end-users have a clear understanding of what happens when they change the resource allocation. I'm not sure lgpu here, at least as specified, passes either. But I also don't have much clue, so pulled Jason in - he understands how this all gets reflected to userspace apis a lot better than me. -Daniel > > > If it's carving up compute power, what's actually being carved up? Time? > > Execution units/waves/threads? Even if that's the case, what advantage > > does it give to have it in terms of a fixed set of lgpus where each cgroup > > gets to pick a fixed set. Does affinity matter that much? Why not just > > say how many waves the GPU supports and that they have to be allocated in > > chunks of 16 waves (pulling a number out of thin air) and let the cgroup > > specify how many waves it wants. > > > > Don't get me wrong here. I'm all for the notion of being able to use > > cgroups to carve up GPU compute resources. However, this sounds to me like > > the most AMD-specific solution possible. We (Intel) could probably do some > > sort of carving up as well but we'd likely want to do it with preemption > > and time-slicing rather than handing out specific EUs. > > This has been discussed in the RFC before > (https://www.spinics.net/lists/cgroups/msg23469.html.) As mentioned > before, the idea of a compute unit is hardly an AMD specific thing as > it is in the OpenCL standard and part of the architecture of many > different vendors. In addition, the interface presented here supports > Intel's use case. What you described is what I considered as the > "anonymous resources" view of the lgpu. What you/Intel can do, is to > register your device to drmcg to have 100 lgpu and users can specify > simply by count. So if they want to allocate 5% for a cgroup, they > would set count=5. Per the documentation in this patch: "Some DRM > devices may only support lgpu as anonymous resources. In such case, > the significance of the position of the set bits in list will be > ignored." What Intel does with the user expressed configuration of "5 > out of 100" is entirely up to Intel (time slice if you like, change to > specific EUs later if you like, or make it driver configurable to > support both if you like.) > > Regards, > Kenny > > > > > On Fri, Feb 14, 2020 at 9:57 AM Kenny Ho wrote: > >> > >> drm.lgpu > >> A read-write nested-keyed file which exists on all cgroups. > >> Each entry is keyed by the DRM device's major:minor. > >> > >> lgpu stands for logical GPU, it is an abstraction used to > >> subdivide a physical DRM device for the purpose of resource > >> management. This file stores user configuration while the > >> drm.lgpu.effective reflects the actual allocation after > >> considering the relationship between the cgroups and their > >> configurations. > >> > >> The lgpu is a discrete quantity that is device specific (i.e. > >> some DRM devices may have 64 lgpus while others may have 100 > >> lgpus.) The lgpu is a single quantity that can be allocated > >> in three different ways denoted by the following nested keys. > >> > >> = == > >> weightAllocate by proportion in relationship with > >> active sibling cgroups > >> count Allocate by amount statically, treat lgpu as > >> anonymous resources > >> list Allocate statically, treat lgpu as named > >> resource > >> = == > >> > >> For example: > >> 226:0 weight=100 count=256 list=0-255 > >> 226:1 weight=100 count=4 list=0,2,4,6 > >> 226:2 weight=100 count=32 list=32-63 > >> 226:3 weight=100 count=0 list= > >> 226:4 weight=500 count=0 list= > >> > >> lgpu is represented by a bitmap and uses the bitmap_parselist > >> kernel function so the list key input format is a > >> comma-separated list of decimal numbers and ranges. > >> > >> Consecutively set bits are shown as two hyphen-separated decimal > >> numbers, the smallest and largest bit numbers set in the range. > >> Optionally each range can be postfixed to denote that only parts > >> of it should be set. The range will divided to groups of > >> specific size. > >>
RE: [PATCH] drm/amd/display: Don't take the address of skip_scdc_overwrite in dc_link_detect_helper
> -Original Message-
> From: Liu, Zhan
> Sent: 2020/February/14, Friday 11:01 AM
> To: Nathan Chancellor ; Wentland, Harry
> ; Li, Sun peng (Leo) ;
> Deucher, Alexander ; Koenig, Christian
> ; Zhou, David(ChunMing)
>
> Cc: clang-built-li...@googlegroups.com; dri-devel@lists.freedesktop.org;
> amd-...@lists.freedesktop.org; linux-ker...@vger.kernel.org
> Subject: RE: [PATCH] drm/amd/display: Don't take the address of
> skip_scdc_overwrite in dc_link_detect_helper
>
>
>
> > -Original Message-
> > From: dri-devel On Behalf Of
> > Nathan Chancellor
> > Sent: 2020/February/14, Friday 1:30 AM
> > To: Wentland, Harry ; Li, Sun peng (Leo)
> > ; Deucher, Alexander
> ;
> > Koenig, Christian ; Zhou, David(ChunMing)
> >
> > Cc: clang-built-li...@googlegroups.com; Nathan Chancellor
> > ; dri-devel@lists.freedesktop.org; amd-
> > g...@lists.freedesktop.org; linux-ker...@vger.kernel.org
> > Subject: [PATCH] drm/amd/display: Don't take the address of
> > skip_scdc_overwrite in dc_link_detect_helper
> >
> > Clang warns:
> >
> > ../drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link.c:980:36:
> > warning: address of 'sink->edid_caps.panel_patch.skip_scdc_overwrite'
> > will always evaluate to 'true' [-Wpointer-bool-conversion]
> > if (>edid_caps.panel_patch.skip_scdc_overwrite)
> > ~~ ^~~
> > 1 warning generated.
> >
> > This is probably not what was intended so remove the address of
> > operator, which matches how skip_scdc_overwrite is handled in the rest of
> the driver.
> >
> > While we're here, drop an extra newline after this if block.
> >
> > Fixes: a760fc1bff03 ("drm/amd/display: add monitor patch to disable
> > SCDC
> > read/write")
> > Link:
> > https://github.com/ClangBuiltLinux/linux/issues/879
> > Signed-off-by: Nathan Chancellor
>
> Thank you!
> Reviewed-by: Zhan Liu
Also applied, thanks!
Zhan
>
> > ---
> >
> > As an aside, I don't see skip_scdc_overwrite assigned a value
> > anywhere, is this working as intended?
> >
> > drivers/gpu/drm/amd/display/dc/core/dc_link.c | 3 +--
> > 1 file changed, 1 insertion(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> > b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> > index 24d99849be5e..a3bfa05c545e 100644
> > --- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> > +++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> > @@ -977,10 +977,9 @@ static bool dc_link_detect_helper(struct dc_link
> > *link,
> > if ((prev_sink != NULL) && ((edid_status == EDID_THE_SAME)
> > || (edid_status == EDID_OK)))
> > same_edid = is_same_edid(_sink->dc_edid,
> >dc_edid);
> >
> > - if (>edid_caps.panel_patch.skip_scdc_overwrite)
> > + if (sink->edid_caps.panel_patch.skip_scdc_overwrite)
> > link->ctx->dc->debug.hdmi20_disable = true;
> >
> > -
> > if (link->connector_signal == SIGNAL_TYPE_DISPLAY_PORT
> &&
> > sink_caps.transaction_type ==
> > DDC_TRANSACTION_TYPE_I2C_OVER_AUX) {
> > /*
> > --
> > 2.25.0
> >
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RESEND] drm/mcde: Fix Sphinx formatting
On Fri, Feb 14, 2020 at 05:38:15PM +0100, Jonathan Neuschäfer wrote: > - Format the pipe diagram as a monospace block. > - Fix formatting of the list. Without the empty line, the first dash is > not parsed as a bullet point. > > Signed-off-by: Jonathan Neuschäfer > --- > Previous copy: > https://lore.kernel.org/lkml/20191002153827.23026-2-j.neuschae...@gmx.net/ > > It seems that this patch got lost, somehow. Occasionally happens with the committer model we have, especially for smaller drivers. Thanks for resending, applied to drm-misc-next now. -Daniel > --- > drivers/gpu/drm/mcde/mcde_drv.c | 9 + > 1 file changed, 5 insertions(+), 4 deletions(-) > > diff --git a/drivers/gpu/drm/mcde/mcde_drv.c b/drivers/gpu/drm/mcde/mcde_drv.c > index 9a09eba53182..c535abed4765 100644 > --- a/drivers/gpu/drm/mcde/mcde_drv.c > +++ b/drivers/gpu/drm/mcde/mcde_drv.c > @@ -20,11 +20,11 @@ > * input formats including most variants of RGB and YUV. > * > * The hardware has four display pipes, and the layout is a little > - * bit like this: > + * bit like this:: > * > - * Memory -> Overlay -> Channel -> FIFO -> 5 formatters -> DSI/DPI > - * External 0..5 0..3 A,B,3 x DSI bridge > - * source 0..9 C0,C1 2 x DPI > + * Memory -> Overlay -> Channel -> FIFO -> 5 formatters -> DSI/DPI > + * External 0..5 0..3 A,B,3 x DSI bridge > + * source 0..9 C0,C1 2 x DPI > * > * FIFOs A and B are for LCD and HDMI while FIFO CO/C1 are for > * panels with embedded buffer. > @@ -43,6 +43,7 @@ > * to change as we exploit more of the hardware capabilities. > * > * TODO: > + * > * - Enabled damaged rectangles using drm_plane_enable_fb_damage_clips() > * so we can selectively just transmit the damaged area to a > * command-only display. > -- > 2.20.1 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
drm/print: clean up RATELIMITED macros
>From 6fdc9c030ba88e6d0d8abc319f3dfe83751d5900 Mon Sep 17 00:00:00 2001
From: Sam Ravnborg
Date: Fri, 14 Feb 2020 18:54:42 +0100
Subject: [PATCH v1 1/1] drm/print: clean up RATELIMITED macros
Drop a few indirections, making the code simpler.
This also drops a RATELIMITED variant that is not in use.
Signed-off-by: Sam Ravnborg
Cc: Jani Nikula
Cc: Daniel Vetter
---
include/drm/drm_print.h | 27 +++
1 file changed, 7 insertions(+), 20 deletions(-)
diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
index fd6ba2532f50..ca7cee8e728a 100644
--- a/include/drm/drm_print.h
+++ b/include/drm/drm_print.h
@@ -383,25 +383,6 @@ void drm_dev_dbg(const struct device *dev, enum
drm_debug_category category,
#define DRM_DEV_DEBUG_KMS(dev, fmt, ...) \
drm_dev_dbg(dev, DRM_UT_KMS, fmt, ##__VA_ARGS__)
-#define _DRM_DEV_DEFINE_DEBUG_RATELIMITED(dev, category, fmt, ...) \
-({ \
- static DEFINE_RATELIMIT_STATE(_rs, \
- DEFAULT_RATELIMIT_INTERVAL, \
- DEFAULT_RATELIMIT_BURST); \
- if (__ratelimit(&_rs)) \
- drm_dev_dbg(dev, category, fmt, ##__VA_ARGS__); \
-})
-
-/**
- * Rate limited debug output. Like DRM_DEBUG() but won't flood the log.
- *
- * @dev: device pointer
- * @fmt: printf() like format string.
- */
-#define DRM_DEV_DEBUG_KMS_RATELIMITED(dev, fmt, ...) \
- _DRM_DEV_DEFINE_DEBUG_RATELIMITED(dev, DRM_UT_KMS, \
- fmt, ##__VA_ARGS__)
-
/*
* struct drm_device based logging
*
@@ -525,7 +506,13 @@ void __drm_err(const char *format, ...);
#define DRM_DEBUG_KMS_RATELIMITED(fmt, ...)\
- DRM_DEV_DEBUG_KMS_RATELIMITED(NULL, fmt, ##__VA_ARGS__)
+({ \
+ static DEFINE_RATELIMIT_STATE(_rs, \
+ DEFAULT_RATELIMIT_INTERVAL, \
+ DEFAULT_RATELIMIT_BURST); \
+ if (__ratelimit(&_rs)) \
+ drm_dev_dbg(NULL, DRM_UT_KMS, fmt, ##__VA_ARGS__); \
+})
/*
* struct drm_device based WARNs
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 09/11] drm, cgroup: Introduce lgpu as DRM cgroup resource
On Fri, Feb 14, 2020 at 11:08 AM Kenny Ho wrote: > > Hi Jason, > > Thanks for the review. > > On Fri, Feb 14, 2020 at 11:44 AM Jason Ekstrand wrote: > > > > Pardon my ignorance but I'm a bit confused by this. What is a "logical > > GPU"? What are we subdividing? Are we carving up memory? Compute power? > > Both? > > The intention is compute but it is up to the individual drm driver to decide. > > > If it's carving up compute power, what's actually being carved up? Time? > > Execution units/waves/threads? Even if that's the case, what advantage > > does it give to have it in terms of a fixed set of lgpus where each cgroup > > gets to pick a fixed set. Does affinity matter that much? Why not just > > say how many waves the GPU supports and that they have to be allocated in > > chunks of 16 waves (pulling a number out of thin air) and let the cgroup > > specify how many waves it wants. > > > > Don't get me wrong here. I'm all for the notion of being able to use > > cgroups to carve up GPU compute resources. However, this sounds to me like > > the most AMD-specific solution possible. We (Intel) could probably do some > > sort of carving up as well but we'd likely want to do it with preemption > > and time-slicing rather than handing out specific EUs. > > This has been discussed in the RFC before > (https://www.spinics.net/lists/cgroups/msg23469.html.) As mentioned > before, the idea of a compute unit is hardly an AMD specific thing as > it is in the OpenCL standard and part of the architecture of many > different vendors. In addition, the interface presented here supports > Intel's use case. What you described is what I considered as the > "anonymous resources" view of the lgpu. What you/Intel can do, is to > register your device to drmcg to have 100 lgpu and users can specify > simply by count. So if they want to allocate 5% for a cgroup, they > would set count=5. Per the documentation in this patch: "Some DRM > devices may only support lgpu as anonymous resources. In such case, > the significance of the position of the set bits in list will be > ignored." What Intel does with the user expressed configuration of "5 > out of 100" is entirely up to Intel (time slice if you like, change to > specific EUs later if you like, or make it driver configurable to > support both if you like.) Sure, there's an OpenCL thing. However, just because there's an OpenCL thing doesn't mean that it's as standardized as it looks. :-( In particular, 1. The OpenCL thing has a query first to ask the driver what kind of carving up of the GPU is allowed 2. When clCreateSubdevices is called, the type of partitioning is specified so they can specifically ask for devices grouped by shared L2 cache, for instance. 3. Just because the API exists and everyone implements it doesn't mean that everyone implements it usefully. From my reading of the spec, it looks like the API is very much designed towards a CPU implementation of OpenCL. The Intel OpenCL GPU compute drivers, for instance, implement it as a total no-op and no real sub-dividing is allowed. That said, that doesn't necessarily mean that carving up units of compute power is a bad plan. It's just unclear (as Daniel said on the above referenced chain) what those units mean. Maybe it's ok if they mean nothing or if their meaning is HW-specific? > Regards, > Kenny > > > > > On Fri, Feb 14, 2020 at 9:57 AM Kenny Ho wrote: > >> > >> drm.lgpu > >> A read-write nested-keyed file which exists on all cgroups. > >> Each entry is keyed by the DRM device's major:minor. > >> > >> lgpu stands for logical GPU, it is an abstraction used to > >> subdivide a physical DRM device for the purpose of resource > >> management. This file stores user configuration while the > >> drm.lgpu.effective reflects the actual allocation after > >> considering the relationship between the cgroups and their > >> configurations. > >> > >> The lgpu is a discrete quantity that is device specific (i.e. > >> some DRM devices may have 64 lgpus while others may have 100 > >> lgpus.) The lgpu is a single quantity that can be allocated > >> in three different ways denoted by the following nested keys. > >> > >> = == > >> weightAllocate by proportion in relationship with > >> active sibling cgroups > >> count Allocate by amount statically, treat lgpu as > >> anonymous resources > >> list Allocate statically, treat lgpu as named > >> resource > >> = == > >> > >> For example: > >> 226:0 weight=100 count=256 list=0-255 > >> 226:1 weight=100 count=4 list=0,2,4,6 > >> 226:2 weight=100 count=32 list=32-63 > >> 226:3 weight=100 count=0 list= > >> 226:4 weight=500 count=0
Re: [PATCH 13/15] drm/amdgpu/display: split dp connector registration (v3)
On Fri, Feb 14, 2020 at 2:39 AM Daniel Vetter wrote:
>
> On Fri, Feb 07, 2020 at 04:17:13PM -0500, Alex Deucher wrote:
> > Split into init and register functions to avoid a segfault
> > in some configs when the load/unload callbacks are removed.
> >
> > v2:
> > - add back accidently dropped has_aux setting
> > - set dev in late_register
> >
> > v3:
> > - fix dp cec ordering
>
> Why did you move this back out of the late_register callback when going
> from v2->v3? In i915 we register the cec stuff from ->late_register, like
I got a bunch of complaints from the cec code when I had it switched
the other way. They went away when I moved it back. I don't remember
the exact messages off hand.
Alex
> anything else userspace visible. Maybe follow-up patch (the idea behind
> removing the ->load callback is to close all the driver load races,
> instead of only open("/dev/dri/0"), which is protected by
> drm_global_mutex). On this:
>
> Reviewed-by: Daniel Vetter
>
> Cheers, Daniel
>
> >
> > Signed-off-by: Alex Deucher
> > ---
> > drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 16
> > drivers/gpu/drm/amd/amdgpu/atombios_dp.c | 10 ++
> > .../amd/display/amdgpu_dm/amdgpu_dm_mst_types.c | 7 ++-
> > 3 files changed, 24 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> > index ec1501e3a63a..f355d9a752d2 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> > @@ -1461,6 +1461,20 @@ static enum drm_mode_status
> > amdgpu_connector_dp_mode_valid(struct drm_connector
> > return MODE_OK;
> > }
> >
> > +static int
> > +amdgpu_connector_late_register(struct drm_connector *connector)
> > +{
> > + struct amdgpu_connector *amdgpu_connector =
> > to_amdgpu_connector(connector);
> > + int r = 0;
> > +
> > + if (amdgpu_connector->ddc_bus->has_aux) {
> > + amdgpu_connector->ddc_bus->aux.dev =
> > amdgpu_connector->base.kdev;
> > + r = drm_dp_aux_register(_connector->ddc_bus->aux);
> > + }
> > +
> > + return r;
> > +}
> > +
> > static const struct drm_connector_helper_funcs
> > amdgpu_connector_dp_helper_funcs = {
> > .get_modes = amdgpu_connector_dp_get_modes,
> > .mode_valid = amdgpu_connector_dp_mode_valid,
> > @@ -1475,6 +1489,7 @@ static const struct drm_connector_funcs
> > amdgpu_connector_dp_funcs = {
> > .early_unregister = amdgpu_connector_unregister,
> > .destroy = amdgpu_connector_destroy,
> > .force = amdgpu_connector_dvi_force,
> > + .late_register = amdgpu_connector_late_register,
> > };
> >
> > static const struct drm_connector_funcs amdgpu_connector_edp_funcs = {
> > @@ -1485,6 +1500,7 @@ static const struct drm_connector_funcs
> > amdgpu_connector_edp_funcs = {
> > .early_unregister = amdgpu_connector_unregister,
> > .destroy = amdgpu_connector_destroy,
> > .force = amdgpu_connector_dvi_force,
> > + .late_register = amdgpu_connector_late_register,
> > };
> >
> > void
> > diff --git a/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
> > b/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
> > index ea702a64f807..9b74cfdba7b8 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
> > @@ -186,16 +186,10 @@ amdgpu_atombios_dp_aux_transfer(struct drm_dp_aux
> > *aux, struct drm_dp_aux_msg *m
> >
> > void amdgpu_atombios_dp_aux_init(struct amdgpu_connector *amdgpu_connector)
> > {
> > - int ret;
> > -
> > amdgpu_connector->ddc_bus->rec.hpd = amdgpu_connector->hpd.hpd;
> > - amdgpu_connector->ddc_bus->aux.dev = amdgpu_connector->base.kdev;
> > amdgpu_connector->ddc_bus->aux.transfer =
> > amdgpu_atombios_dp_aux_transfer;
> > - ret = drm_dp_aux_register(_connector->ddc_bus->aux);
> > - if (!ret)
> > - amdgpu_connector->ddc_bus->has_aux = true;
> > -
> > - WARN(ret, "drm_dp_aux_register_i2c_bus() failed with error %d\n",
> > ret);
> > + drm_dp_aux_init(_connector->ddc_bus->aux);
> > + amdgpu_connector->ddc_bus->has_aux = true;
> > }
> >
> > /* general DP utility functions */
> > diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> > b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> > index 3959c942c88b..d5b9e72f2649 100644
> > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> > @@ -155,6 +155,11 @@ amdgpu_dm_mst_connector_late_register(struct
> > drm_connector *connector)
> > struct amdgpu_dm_connector *amdgpu_dm_connector =
> > to_amdgpu_dm_connector(connector);
> > struct drm_dp_mst_port *port = amdgpu_dm_connector->port;
> > + int r;
> > +
> > + r = drm_dp_aux_register(_dm_connector->dm_dp_aux.aux);
> > + if (r)
> > +
Re: [PATCH 09/11] drm, cgroup: Introduce lgpu as DRM cgroup resource
Hi Jason, Thanks for the review. On Fri, Feb 14, 2020 at 11:44 AM Jason Ekstrand wrote: > > Pardon my ignorance but I'm a bit confused by this. What is a "logical GPU"? > What are we subdividing? Are we carving up memory? Compute power? Both? The intention is compute but it is up to the individual drm driver to decide. > If it's carving up compute power, what's actually being carved up? Time? > Execution units/waves/threads? Even if that's the case, what advantage does > it give to have it in terms of a fixed set of lgpus where each cgroup gets to > pick a fixed set. Does affinity matter that much? Why not just say how many > waves the GPU supports and that they have to be allocated in chunks of 16 > waves (pulling a number out of thin air) and let the cgroup specify how many > waves it wants. > > Don't get me wrong here. I'm all for the notion of being able to use cgroups > to carve up GPU compute resources. However, this sounds to me like the most > AMD-specific solution possible. We (Intel) could probably do some sort of > carving up as well but we'd likely want to do it with preemption and > time-slicing rather than handing out specific EUs. This has been discussed in the RFC before (https://www.spinics.net/lists/cgroups/msg23469.html.) As mentioned before, the idea of a compute unit is hardly an AMD specific thing as it is in the OpenCL standard and part of the architecture of many different vendors. In addition, the interface presented here supports Intel's use case. What you described is what I considered as the "anonymous resources" view of the lgpu. What you/Intel can do, is to register your device to drmcg to have 100 lgpu and users can specify simply by count. So if they want to allocate 5% for a cgroup, they would set count=5. Per the documentation in this patch: "Some DRM devices may only support lgpu as anonymous resources. In such case, the significance of the position of the set bits in list will be ignored." What Intel does with the user expressed configuration of "5 out of 100" is entirely up to Intel (time slice if you like, change to specific EUs later if you like, or make it driver configurable to support both if you like.) Regards, Kenny > > On Fri, Feb 14, 2020 at 9:57 AM Kenny Ho wrote: >> >> drm.lgpu >> A read-write nested-keyed file which exists on all cgroups. >> Each entry is keyed by the DRM device's major:minor. >> >> lgpu stands for logical GPU, it is an abstraction used to >> subdivide a physical DRM device for the purpose of resource >> management. This file stores user configuration while the >> drm.lgpu.effective reflects the actual allocation after >> considering the relationship between the cgroups and their >> configurations. >> >> The lgpu is a discrete quantity that is device specific (i.e. >> some DRM devices may have 64 lgpus while others may have 100 >> lgpus.) The lgpu is a single quantity that can be allocated >> in three different ways denoted by the following nested keys. >> >> = == >> weightAllocate by proportion in relationship with >> active sibling cgroups >> count Allocate by amount statically, treat lgpu as >> anonymous resources >> list Allocate statically, treat lgpu as named >> resource >> = == >> >> For example: >> 226:0 weight=100 count=256 list=0-255 >> 226:1 weight=100 count=4 list=0,2,4,6 >> 226:2 weight=100 count=32 list=32-63 >> 226:3 weight=100 count=0 list= >> 226:4 weight=500 count=0 list= >> >> lgpu is represented by a bitmap and uses the bitmap_parselist >> kernel function so the list key input format is a >> comma-separated list of decimal numbers and ranges. >> >> Consecutively set bits are shown as two hyphen-separated decimal >> numbers, the smallest and largest bit numbers set in the range. >> Optionally each range can be postfixed to denote that only parts >> of it should be set. The range will divided to groups of >> specific size. >> Syntax: range:used_size/group_size >> Example: 0-1023:2/256 ==> 0,1,256,257,512,513,768,769 >> >> The count key is the hamming weight / hweight of the bitmap. >> >> Weight, count and list accept the max and default keywords. >> >> Some DRM devices may only support lgpu as anonymous resources. >> In such case, the significance of the position of the set bits >> in list will be ignored. >> >> The weight quantity is only in effect when static allocation >> is not used (by setting count=0) for this cgroup. The weight >> quantity distributes lgpus that are not statically allocated by >> the siblings. For example, given siblings cgroupA,
Re: [PATCH 09/11] drm, cgroup: Introduce lgpu as DRM cgroup resource
On Fri, Feb 14, 2020 at 10:44 AM Jason Ekstrand wrote: > > Pardon my ignorance but I'm a bit confused by this. What is a "logical GPU"? > What are we subdividing? Are we carving up memory? Compute power? Both? > > If it's carving up memory, why aren't we just measuring it in megabytes? > > If it's carving up compute power, what's actually being carved up? Time? > Execution units/waves/threads? Even if that's the case, what advantage does > it give to have it in terms of a fixed set of lgpus where each cgroup gets to > pick a fixed set. Does affinity matter that much? Why not just say how many > waves the GPU supports and that they have to be allocated in chunks of 16 > waves (pulling a number out of thin air) and let the cgroup specify how many > waves it wants. One more question: If I'm a userspace driver, and there are 14 lgpus allocated to my cgroup, does that mean I have 14 GPUs? Or does that mean I have one GPU with 14 units of compute power? > Don't get me wrong here. I'm all for the notion of being able to use cgroups > to carve up GPU compute resources. However, this sounds to me like the most > AMD-specific solution possible. We (Intel) could probably do some sort of > carving up as well but we'd likely want to do it with preemption and > time-slicing rather than handing out specific EUs. Ok, so "most AMD-specific solution possible" probably wasn't fair. However, it does seem like an unnecessarily rigid solution to me. Maybe there's something I'm not getting? --Jason > --Jason > > > On Fri, Feb 14, 2020 at 9:57 AM Kenny Ho wrote: >> >> drm.lgpu >> A read-write nested-keyed file which exists on all cgroups. >> Each entry is keyed by the DRM device's major:minor. >> >> lgpu stands for logical GPU, it is an abstraction used to >> subdivide a physical DRM device for the purpose of resource >> management. This file stores user configuration while the >> drm.lgpu.effective reflects the actual allocation after >> considering the relationship between the cgroups and their >> configurations. >> >> The lgpu is a discrete quantity that is device specific (i.e. >> some DRM devices may have 64 lgpus while others may have 100 >> lgpus.) The lgpu is a single quantity that can be allocated >> in three different ways denoted by the following nested keys. >> >> = == >> weightAllocate by proportion in relationship with >> active sibling cgroups >> count Allocate by amount statically, treat lgpu as >> anonymous resources >> list Allocate statically, treat lgpu as named >> resource >> = == >> >> For example: >> 226:0 weight=100 count=256 list=0-255 >> 226:1 weight=100 count=4 list=0,2,4,6 >> 226:2 weight=100 count=32 list=32-63 >> 226:3 weight=100 count=0 list= >> 226:4 weight=500 count=0 list= >> >> lgpu is represented by a bitmap and uses the bitmap_parselist >> kernel function so the list key input format is a >> comma-separated list of decimal numbers and ranges. >> >> Consecutively set bits are shown as two hyphen-separated decimal >> numbers, the smallest and largest bit numbers set in the range. >> Optionally each range can be postfixed to denote that only parts >> of it should be set. The range will divided to groups of >> specific size. >> Syntax: range:used_size/group_size >> Example: 0-1023:2/256 ==> 0,1,256,257,512,513,768,769 >> >> The count key is the hamming weight / hweight of the bitmap. >> >> Weight, count and list accept the max and default keywords. >> >> Some DRM devices may only support lgpu as anonymous resources. >> In such case, the significance of the position of the set bits >> in list will be ignored. >> >> The weight quantity is only in effect when static allocation >> is not used (by setting count=0) for this cgroup. The weight >> quantity distributes lgpus that are not statically allocated by >> the siblings. For example, given siblings cgroupA, cgroupB and >> cgroupC for a DRM device that has 64 lgpus, if cgroupA occupies >> 0-63, no lgpu is available to be distributed by weight. >> Similarly, if cgroupA has list=0-31 and cgroupB has list=16-63, >> cgroupC will be starved if it tries to allocate by weight. >> >> On the other hand, if cgroupA has weight=100 count=0, cgroupB >> has list=16-47, and cgroupC has weight=100 count=0, then 32 >> lgpus are available to be distributed evenly between cgroupA >> and cgroupC. In drm.lgpu.effective, cgroupA will have >> list=0-15 and cgroupC will have list=48-63. >> >> This lgpu resource supports the 'allocation' and 'weight'
Re: [PATCH AUTOSEL 4.19 246/252] drm/amdgpu/smu10: fix smu10_get_clock_by_type_with_voltage
On Fri, Feb 14, 2020 at 11:17 AM Sasha Levin wrote:
>
> From: Alex Deucher
>
> [ Upstream commit 1064ad4aeef94f51ca230ac639a9e996fb7867a0 ]
>
> Cull out 0 clocks to avoid a warning in DC.
>
> Bug: https://gitlab.freedesktop.org/drm/amd/issues/963
Same comment as for 5.5. All of the upstream patches that reference
that bug need to be applied or they all need to be dropped.
Alex
> Reviewed-by: Evan Quan
> Signed-off-by: Alex Deucher
> Signed-off-by: Sasha Levin
> ---
> drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c | 8 +---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c
> b/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c
> index 3fa6e8123b8eb..48e31711bc68f 100644
> --- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c
> +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c
> @@ -1048,9 +1048,11 @@ static int smu10_get_clock_by_type_with_voltage(struct
> pp_hwmgr *hwmgr,
>
> clocks->num_levels = 0;
> for (i = 0; i < pclk_vol_table->count; i++) {
> - clocks->data[i].clocks_in_khz =
> pclk_vol_table->entries[i].clk * 10;
> - clocks->data[i].voltage_in_mv =
> pclk_vol_table->entries[i].vol;
> - clocks->num_levels++;
> + if (pclk_vol_table->entries[i].clk) {
> + clocks->data[clocks->num_levels].clocks_in_khz =
> pclk_vol_table->entries[i].clk * 10;
> + clocks->data[clocks->num_levels].voltage_in_mv =
> pclk_vol_table->entries[i].vol;
> + clocks->num_levels++;
> + }
> }
>
> return 0;
> --
> 2.20.1
>
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 09/11] drm, cgroup: Introduce lgpu as DRM cgroup resource
Pardon my ignorance but I'm a bit confused by this. What is a "logical GPU"? What are we subdividing? Are we carving up memory? Compute power? Both? If it's carving up memory, why aren't we just measuring it in megabytes? If it's carving up compute power, what's actually being carved up? Time? Execution units/waves/threads? Even if that's the case, what advantage does it give to have it in terms of a fixed set of lgpus where each cgroup gets to pick a fixed set. Does affinity matter that much? Why not just say how many waves the GPU supports and that they have to be allocated in chunks of 16 waves (pulling a number out of thin air) and let the cgroup specify how many waves it wants. Don't get me wrong here. I'm all for the notion of being able to use cgroups to carve up GPU compute resources. However, this sounds to me like the most AMD-specific solution possible. We (Intel) could probably do some sort of carving up as well but we'd likely want to do it with preemption and time-slicing rather than handing out specific EUs. --Jason On Fri, Feb 14, 2020 at 9:57 AM Kenny Ho wrote: > drm.lgpu > A read-write nested-keyed file which exists on all cgroups. > Each entry is keyed by the DRM device's major:minor. > > lgpu stands for logical GPU, it is an abstraction used to > subdivide a physical DRM device for the purpose of resource > management. This file stores user configuration while the > drm.lgpu.effective reflects the actual allocation after > considering the relationship between the cgroups and their > configurations. > > The lgpu is a discrete quantity that is device specific (i.e. > some DRM devices may have 64 lgpus while others may have 100 > lgpus.) The lgpu is a single quantity that can be allocated > in three different ways denoted by the following nested keys. > > = == > weightAllocate by proportion in relationship with > active sibling cgroups > count Allocate by amount statically, treat lgpu as > anonymous resources > list Allocate statically, treat lgpu as named > resource > = == > > For example: > 226:0 weight=100 count=256 list=0-255 > 226:1 weight=100 count=4 list=0,2,4,6 > 226:2 weight=100 count=32 list=32-63 > 226:3 weight=100 count=0 list= > 226:4 weight=500 count=0 list= > > lgpu is represented by a bitmap and uses the bitmap_parselist > kernel function so the list key input format is a > comma-separated list of decimal numbers and ranges. > > Consecutively set bits are shown as two hyphen-separated decimal > numbers, the smallest and largest bit numbers set in the range. > Optionally each range can be postfixed to denote that only parts > of it should be set. The range will divided to groups of > specific size. > Syntax: range:used_size/group_size > Example: 0-1023:2/256 ==> 0,1,256,257,512,513,768,769 > > The count key is the hamming weight / hweight of the bitmap. > > Weight, count and list accept the max and default keywords. > > Some DRM devices may only support lgpu as anonymous resources. > In such case, the significance of the position of the set bits > in list will be ignored. > > The weight quantity is only in effect when static allocation > is not used (by setting count=0) for this cgroup. The weight > quantity distributes lgpus that are not statically allocated by > the siblings. For example, given siblings cgroupA, cgroupB and > cgroupC for a DRM device that has 64 lgpus, if cgroupA occupies > 0-63, no lgpu is available to be distributed by weight. > Similarly, if cgroupA has list=0-31 and cgroupB has list=16-63, > cgroupC will be starved if it tries to allocate by weight. > > On the other hand, if cgroupA has weight=100 count=0, cgroupB > has list=16-47, and cgroupC has weight=100 count=0, then 32 > lgpus are available to be distributed evenly between cgroupA > and cgroupC. In drm.lgpu.effective, cgroupA will have > list=0-15 and cgroupC will have list=48-63. > > This lgpu resource supports the 'allocation' and 'weight' > resource distribution model. > > drm.lgpu.effective > A read-only nested-keyed file which exists on all cgroups. > Each entry is keyed by the DRM device's major:minor. > > lgpu stands for logical GPU, it is an abstraction used to > subdivide a physical DRM device for the purpose of resource > management. This file reflects the actual allocation after > considering the relationship between the cgroups and their > configurations in drm.lgpu. > > Change-Id: Idde0ef9a331fd67bb9c7eb8ef9978439e6452488 >
Re: [PATCH AUTOSEL 5.5 530/542] drm/amdgpu/smu10: fix smu10_get_clock_by_type_with_voltage
On Fri, Feb 14, 2020 at 11:00 AM Sasha Levin wrote:
>
> From: Alex Deucher
>
> [ Upstream commit 1064ad4aeef94f51ca230ac639a9e996fb7867a0 ]
>
> Cull out 0 clocks to avoid a warning in DC.
>
> Bug: https://gitlab.freedesktop.org/drm/amd/issues/963
All of the upstream commits that reference this bug need to be applied
or this patch set will be broken. Please either apply them all or
drop them.
Alex
> Reviewed-by: Evan Quan
> Signed-off-by: Alex Deucher
> Signed-off-by: Sasha Levin
> ---
> drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c | 8 +---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c
> b/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c
> index 627a42e8fd318..fed3fc4bb57a9 100644
> --- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c
> +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c
> @@ -1080,9 +1080,11 @@ static int smu10_get_clock_by_type_with_voltage(struct
> pp_hwmgr *hwmgr,
>
> clocks->num_levels = 0;
> for (i = 0; i < pclk_vol_table->count; i++) {
> - clocks->data[i].clocks_in_khz =
> pclk_vol_table->entries[i].clk * 10;
> - clocks->data[i].voltage_in_mv =
> pclk_vol_table->entries[i].vol;
> - clocks->num_levels++;
> + if (pclk_vol_table->entries[i].clk) {
> + clocks->data[clocks->num_levels].clocks_in_khz =
> pclk_vol_table->entries[i].clk * 10;
> + clocks->data[clocks->num_levels].voltage_in_mv =
> pclk_vol_table->entries[i].vol;
> + clocks->num_levels++;
> + }
> }
>
> return 0;
> --
> 2.20.1
>
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.4 093/100] radeon: insert 10ms sleep in dce5_crtc_load_lut
From: Daniel Vetter
[ Upstream commit ec3d65082d7dabad6fa8f66a8ef166f2d522d6b2 ]
Per at least one tester this is enough magic to recover the regression
introduced for some people (but not all) in
commit b8e2b0199cc377617dc238f5106352c06dcd3fa2
Author: Peter Rosin
Date: Tue Jul 4 12:36:57 2017 +0200
drm/fb-helper: factor out pseudo-palette
which for radeon had the side-effect of refactoring out a seemingly
redudant writing of the color palette.
10ms in a fairly slow modeset path feels like an acceptable form of
duct-tape, so maybe worth a shot and see what sticks.
Cc: Alex Deucher
Cc: Michel Dänzer
References: https://bugzilla.kernel.org/show_bug.cgi?id=198123
Signed-off-by: Daniel Vetter
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/radeon/radeon_display.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/radeon/radeon_display.c
b/drivers/gpu/drm/radeon/radeon_display.c
index b26e4eae7ac54..2e3bc48fb1eb7 100644
--- a/drivers/gpu/drm/radeon/radeon_display.c
+++ b/drivers/gpu/drm/radeon/radeon_display.c
@@ -110,6 +110,8 @@ static void dce5_crtc_load_lut(struct drm_crtc *crtc)
DRM_DEBUG_KMS("%d\n", radeon_crtc->crtc_id);
+ msleep(10);
+
WREG32(NI_INPUT_CSC_CONTROL + radeon_crtc->crtc_offset,
(NI_INPUT_CSC_GRPH_MODE(NI_INPUT_CSC_BYPASS) |
NI_INPUT_CSC_OVL_MODE(NI_INPUT_CSC_BYPASS)));
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.4 090/100] drm/nouveau/disp/nv50-: prevent oops when no channel method map provided
From: Ben Skeggs
[ Upstream commit 0e6176c6d286316e9431b4f695940cfac4ffe6c2 ]
The implementations for most channel types contains a map of methods to
priv registers in order to provide debugging info when a disp exception
has been raised.
This info is missing from the implementation of PIO channels as they're
rather simplistic already, however, if an exception is raised by one of
them, we'd end up triggering a NULL-pointer deref. Not ideal...
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=206299
Signed-off-by: Ben Skeggs
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/nouveau/nvkm/engine/disp/channv50.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/disp/channv50.c
b/drivers/gpu/drm/nouveau/nvkm/engine/disp/channv50.c
index 01803c0679b68..d012df9fb9df0 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/disp/channv50.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/disp/channv50.c
@@ -72,6 +72,8 @@ nv50_disp_chan_mthd(struct nv50_disp_chan *chan, int debug)
if (debug > subdev->debug)
return;
+ if (!mthd)
+ return;
for (i = 0; (list = mthd->data[i].mthd) != NULL; i++) {
u32 base = chan->head * mthd->addr;
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/print: Delete a few unused shouting macros
On Fri, Feb 14, 2020 at 11:13:23AM +0200, Jani Nikula wrote:
> On Fri, 14 Feb 2020, Daniel Vetter wrote:
> > We want to go over to the new lowercase ones, encourage that a bit
> > more.
> >
> > Cc: Jani Nikula
> > Signed-off-by: Daniel Vetter
> > ---
> > drivers/gpu/drm/drm_managed.c | 21 +
>
> Oops?
Indeed, tiny sneak peek at what I'm working on ... you mentioning devm_
yesterday was a very successful nerd snipe :-)
>
> > include/drm/drm_print.h | 26 --
>
> Acked-by: Jani Nikula
>
> for this file.
Wrong hunk dropped and applied, thanks for taking a look.
-Daniel
>
> > 2 files changed, 21 insertions(+), 26 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_managed.c b/drivers/gpu/drm/drm_managed.c
> > index ea49071b16ee..7d4827b79806 100644
> > --- a/drivers/gpu/drm/drm_managed.c
> > +++ b/drivers/gpu/drm/drm_managed.c
> > @@ -38,4 +38,25 @@ struct drmres {
> > u8 __aligned(ARCH_KMALLOC_MINALIGN) data[];
> > };
> >
> > +static __always_inline struct drmres * alloc_dr(drmres_release_t release,
> > + size_t size, gfp_t gfp, int nid)
> > +{
> > + size_t tot_size;
> > + struct drmres *dr;
> > +
> > + /* We must catch any near-SIZE_MAX cases that could overflow. */
> > + if (unlikely(check_add_overflow(sizeof(*dr), size, _size)))
> > + return NULL;
> > +
> > + dr = kmalloc_node_track_caller(tot_size, gfp, nid);
> > + if (unlikely(!dr))
> > + return NULL;
> > +
> > + memset(dr, 0, offsetof(struct drmres, data));
> > +
> > + INIT_LIST_HEAD(>node.entry);
> > + dr->node.release = release;
> > + return dr;
> > +}
> > +
> >
> > diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
> > index 894a0b9437e2..fd6ba2532f50 100644
> > --- a/include/drm/drm_print.h
> > +++ b/include/drm/drm_print.h
> > @@ -382,14 +382,6 @@ void drm_dev_dbg(const struct device *dev, enum
> > drm_debug_category category,
> > drm_dev_dbg(dev, DRM_UT_DRIVER, fmt, ##__VA_ARGS__)
> > #define DRM_DEV_DEBUG_KMS(dev, fmt, ...) \
> > drm_dev_dbg(dev, DRM_UT_KMS, fmt, ##__VA_ARGS__)
> > -#define DRM_DEV_DEBUG_PRIME(dev, fmt, ...) \
> > - drm_dev_dbg(dev, DRM_UT_PRIME, fmt, ##__VA_ARGS__)
> > -#define DRM_DEV_DEBUG_ATOMIC(dev, fmt, ...)
> > \
> > - drm_dev_dbg(dev, DRM_UT_ATOMIC, fmt, ##__VA_ARGS__)
> > -#define DRM_DEV_DEBUG_VBL(dev, fmt, ...) \
> > - drm_dev_dbg(dev, DRM_UT_VBL, fmt, ##__VA_ARGS__)
> > -#defineDRM_DEV_DEBUG_DP(dev, fmt, ...)
> > \
> > - drm_dev_dbg(dev, DRM_UT_DP, fmt, ## __VA_ARGS__)
> >
> > #define _DRM_DEV_DEFINE_DEBUG_RATELIMITED(dev, category, fmt, ...) \
> > ({ \
> > @@ -406,18 +398,9 @@ void drm_dev_dbg(const struct device *dev, enum
> > drm_debug_category category,
> > * @dev: device pointer
> > * @fmt: printf() like format string.
> > */
> > -#define DRM_DEV_DEBUG_RATELIMITED(dev, fmt, ...) \
> > - _DEV_DRM_DEFINE_DEBUG_RATELIMITED(dev, DRM_UT_CORE, \
> > - fmt, ##__VA_ARGS__)
> > -#define DRM_DEV_DEBUG_DRIVER_RATELIMITED(dev, fmt, ...)
> > \
> > - _DRM_DEV_DEFINE_DEBUG_RATELIMITED(dev, DRM_UT_DRIVER, \
> > - fmt, ##__VA_ARGS__)
> > #define DRM_DEV_DEBUG_KMS_RATELIMITED(dev, fmt, ...)
> > \
> > _DRM_DEV_DEFINE_DEBUG_RATELIMITED(dev, DRM_UT_KMS, \
> > fmt, ##__VA_ARGS__)
> > -#define DRM_DEV_DEBUG_PRIME_RATELIMITED(dev, fmt, ...)
> > \
> > - _DRM_DEV_DEFINE_DEBUG_RATELIMITED(dev, DRM_UT_PRIME,\
> > - fmt, ##__VA_ARGS__)
> >
> > /*
> > * struct drm_device based logging
> > @@ -541,18 +524,9 @@ void __drm_err(const char *format, ...);
> > __drm_dbg(DRM_UT_DP, fmt, ## __VA_ARGS__)
> >
> >
> > -#define DRM_DEBUG_RATELIMITED(fmt, ...)
> > \
> > - DRM_DEV_DEBUG_RATELIMITED(NULL, fmt, ##__VA_ARGS__)
> > -
> > -#define DRM_DEBUG_DRIVER_RATELIMITED(fmt, ...)
> > \
> > - DRM_DEV_DEBUG_DRIVER_RATELIMITED(NULL, fmt, ##__VA_ARGS__)
> > -
> > #define DRM_DEBUG_KMS_RATELIMITED(fmt, ...)
> > \
> > DRM_DEV_DEBUG_KMS_RATELIMITED(NULL, fmt, ##__VA_ARGS__)
> >
> > -#define DRM_DEBUG_PRIME_RATELIMITED(fmt, ...)
> > \
> > - DRM_DEV_DEBUG_PRIME_RATELIMITED(NULL, fmt, ##__VA_ARGS__)
> > -
> > /*
> > * struct drm_device based WARNs
> > *
>
> --
> Jani Nikula, Intel Open Source Graphics Center
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH AUTOSEL 4.4 071/100] drm/vmwgfx: prevent memory leak in vmw_cmdbuf_res_add
From: Navid Emamdoost
[ Upstream commit 40efb09a7f53125719e49864da008495e39aaa1e ]
In vmw_cmdbuf_res_add if drm_ht_insert_item fails the allocated memory
for cres should be released.
Fixes: 18e4a4669c50 ("drm/vmwgfx: Fix compat shader namespace")
Signed-off-by: Navid Emamdoost
Reviewed-by: Thomas Hellstrom
Signed-off-by: Thomas Hellstrom
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf_res.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf_res.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf_res.c
index 1f013d45c9e9a..0c7c3005594cc 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf_res.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf_res.c
@@ -210,8 +210,10 @@ int vmw_cmdbuf_res_add(struct vmw_cmdbuf_res_manager *man,
cres->hash.key = user_key | (res_type << 24);
ret = drm_ht_insert_item(>resources, >hash);
- if (unlikely(ret != 0))
+ if (unlikely(ret != 0)) {
+ kfree(cres);
goto out_invalid_key;
+ }
cres->state = VMW_CMDBUF_RES_ADD;
cres->res = vmw_resource_reference(res);
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.4 070/100] drm/nouveau: Fix copy-paste error in nouveau_fence_wait_uevent_handler
From: YueHaibing
[ Upstream commit 1eb013473bff5f95b6fe1ca4dd7deda47257b9c2 ]
Like other cases, it should use rcu protected 'chan' rather
than 'fence->channel' in nouveau_fence_wait_uevent_handler.
Fixes: 0ec5f02f0e2c ("drm/nouveau: prevent stale fence->channel pointers, and
protect with rcu")
Signed-off-by: YueHaibing
Signed-off-by: Ben Skeggs
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/nouveau/nouveau_fence.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c
b/drivers/gpu/drm/nouveau/nouveau_fence.c
index 574c36b492ee4..fccec23731e24 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fence.c
+++ b/drivers/gpu/drm/nouveau/nouveau_fence.c
@@ -157,7 +157,7 @@ nouveau_fence_wait_uevent_handler(struct nvif_notify
*notify)
fence = list_entry(fctx->pending.next, typeof(*fence), head);
chan = rcu_dereference_protected(fence->channel,
lockdep_is_held(>lock));
- if (nouveau_fence_update(fence->channel, fctx))
+ if (nouveau_fence_update(chan, fctx))
ret = NVIF_NOTIFY_DROP;
}
spin_unlock_irqrestore(>lock, flags);
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.4 022/100] drm/amdgpu: remove set but not used variable 'dig_connector'
From: yu kuai
[ Upstream commit 5bea7fedb7fe4d5e6d3ba9f385dd3619fb004ce7 ]
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/amd/amdgpu/atombios_dp.c: In function
‘amdgpu_atombios_dp_get_panel_mode’:
drivers/gpu/drm/amd/amdgpu/atombios_dp.c:364:36: warning: variable
‘dig_connector’ set but not used [-Wunused-but-set-variable]
It is never used, so can be removed.
Fixes: d38ceaf99ed0 ("drm/amdgpu: add core driver (v4)")
Signed-off-by: yu kuai
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdgpu/atombios_dp.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
b/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
index 7f85c2c1d6815..120a5fd992081 100644
--- a/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
+++ b/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
@@ -363,7 +363,6 @@ int amdgpu_atombios_dp_get_panel_mode(struct drm_encoder
*encoder,
struct drm_connector *connector)
{
struct amdgpu_connector *amdgpu_connector =
to_amdgpu_connector(connector);
- struct amdgpu_connector_atom_dig *dig_connector;
int panel_mode = DP_PANEL_MODE_EXTERNAL_DP_MODE;
u16 dp_bridge =
amdgpu_connector_encoder_get_dp_bridge_encoder_id(connector);
u8 tmp;
@@ -371,8 +370,6 @@ int amdgpu_atombios_dp_get_panel_mode(struct drm_encoder
*encoder,
if (!amdgpu_connector->con_priv)
return panel_mode;
- dig_connector = amdgpu_connector->con_priv;
-
if (dp_bridge != ENCODER_OBJECT_ID_NONE) {
/* DP bridge chips */
if (drm_dp_dpcd_readb(_connector->ddc_bus->aux,
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.4 034/100] drm/radeon: remove set but not used variable 'blocks'
From: zhengbin
[ Upstream commit 77441f77949807fda4a0aec0bdf3e86ae863fd56 ]
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/radeon/radeon_combios.c: In function
radeon_combios_get_power_modes:
drivers/gpu/drm/radeon/radeon_combios.c:2638:10: warning: variable blocks set
but not used [-Wunused-but-set-variable]
It is introduced by commit 56278a8edace ("drm/radeon/kms:
pull power mode info from bios tables (v3)"), but never used,
so remove it.
Reported-by: Hulk Robot
Signed-off-by: zhengbin
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/radeon/radeon_combios.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_combios.c
b/drivers/gpu/drm/radeon/radeon_combios.c
index fcecaf5b55267..7a3e996fe9f6a 100644
--- a/drivers/gpu/drm/radeon/radeon_combios.c
+++ b/drivers/gpu/drm/radeon/radeon_combios.c
@@ -2636,7 +2636,7 @@ void radeon_combios_get_power_modes(struct radeon_device
*rdev)
{
struct drm_device *dev = rdev->ddev;
u16 offset, misc, misc2 = 0;
- u8 rev, blocks, tmp;
+ u8 rev, tmp;
int state_index = 0;
struct radeon_i2c_bus_rec i2c_bus;
@@ -2726,7 +2726,6 @@ void radeon_combios_get_power_modes(struct radeon_device
*rdev)
offset = combios_get_table_offset(dev,
COMBIOS_POWERPLAY_INFO_TABLE);
if (offset) {
rev = RBIOS8(offset);
- blocks = RBIOS8(offset + 0x2);
/* power mode 0 tends to be the only valid one */
rdev->pm.power_state[state_index].num_clock_modes = 1;
rdev->pm.power_state[state_index].clock_info[0].mclk =
RBIOS32(offset + 0x5 + 0x2);
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.4 032/100] drm/radeon: remove set but not used variable 'dig_connector'
From: zhengbin
[ Upstream commit 3f47f0301594c4f930a32bd7d8125cfdeb6b4b6e ]
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/radeon/atombios_dp.c: In function radeon_dp_get_panel_mode:
drivers/gpu/drm/radeon/atombios_dp.c:415:36: warning: variable dig_connector
set but not used [-Wunused-but-set-variable]
It is not used since commit 379dfc25e257 ("drm/radeon/dp:
switch to the common i2c over aux code")
Reported-by: Hulk Robot
Signed-off-by: zhengbin
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/radeon/atombios_dp.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/radeon/atombios_dp.c
b/drivers/gpu/drm/radeon/atombios_dp.c
index 0c6216a6ee9e0..7eef575da63fa 100644
--- a/drivers/gpu/drm/radeon/atombios_dp.c
+++ b/drivers/gpu/drm/radeon/atombios_dp.c
@@ -413,7 +413,6 @@ int radeon_dp_get_panel_mode(struct drm_encoder *encoder,
struct drm_device *dev = encoder->dev;
struct radeon_device *rdev = dev->dev_private;
struct radeon_connector *radeon_connector =
to_radeon_connector(connector);
- struct radeon_connector_atom_dig *dig_connector;
int panel_mode = DP_PANEL_MODE_EXTERNAL_DP_MODE;
u16 dp_bridge =
radeon_connector_encoder_get_dp_bridge_encoder_id(connector);
u8 tmp;
@@ -424,8 +423,6 @@ int radeon_dp_get_panel_mode(struct drm_encoder *encoder,
if (!radeon_connector->con_priv)
return panel_mode;
- dig_connector = radeon_connector->con_priv;
-
if (dp_bridge != ENCODER_OBJECT_ID_NONE) {
/* DP bridge chips */
if (drm_dp_dpcd_readb(_connector->ddc_bus->aux,
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.4 058/100] drm/gma500: remove set but not used variables 'hist_reg'
From: Chen Zhou
[ Upstream commit 72f775611daf3ce20358388facbaf11f22899fa2 ]
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/gma500/psb_irq.c: In function psb_irq_turn_off_dpst:
drivers/gpu/drm/gma500/psb_irq.c:473:6:
warning: variable hist_reg set but not used [-Wunused-but-set-variable]
Reported-by: Hulk Robot
Signed-off-by: Chen Zhou
Signed-off-by: Patrik Jakobsson
Link:
https://patchwork.freedesktop.org/patch/msgid/20191227114811.14907-1-chenzho...@huawei.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/gma500/psb_irq.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/gma500/psb_irq.c b/drivers/gpu/drm/gma500/psb_irq.c
index f75f199c84311..518d7b4456bf1 100644
--- a/drivers/gpu/drm/gma500/psb_irq.c
+++ b/drivers/gpu/drm/gma500/psb_irq.c
@@ -471,12 +471,11 @@ void psb_irq_turn_off_dpst(struct drm_device *dev)
{
struct drm_psb_private *dev_priv =
(struct drm_psb_private *) dev->dev_private;
- u32 hist_reg;
u32 pwm_reg;
if (gma_power_begin(dev, false)) {
PSB_WVDC32(0x, HISTOGRAM_INT_CONTROL);
- hist_reg = PSB_RVDC32(HISTOGRAM_INT_CONTROL);
+ PSB_RVDC32(HISTOGRAM_INT_CONTROL);
psb_disable_pipestat(dev_priv, 0, PIPE_DPST_EVENT_ENABLE);
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.4 035/100] drm/radeon: remove set but not used variable 'tv_pll_cntl1'
From: zhengbin
[ Upstream commit dc9b3dbd28744510b78490dc6312848a8f918749 ]
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/radeon/radeon_legacy_tv.c: In function
radeon_legacy_tv_mode_set:
drivers/gpu/drm/radeon/radeon_legacy_tv.c:538:24: warning: variable
tv_pll_cntl1 set but not used [-Wunused-but-set-variable]
It is introduced by commit 4ce001abafaf ("drm/radeon/kms:
add initial radeon tv-out support."), but never used,
so remove it.
Reported-by: Hulk Robot
Signed-off-by: zhengbin
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/radeon/radeon_legacy_tv.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_legacy_tv.c
b/drivers/gpu/drm/radeon/radeon_legacy_tv.c
index 49750d07ab7d4..3133f5dfc239a 100644
--- a/drivers/gpu/drm/radeon/radeon_legacy_tv.c
+++ b/drivers/gpu/drm/radeon/radeon_legacy_tv.c
@@ -544,7 +544,7 @@ void radeon_legacy_tv_mode_set(struct drm_encoder *encoder,
uint32_t tv_master_cntl, tv_rgb_cntl, tv_dac_cntl;
uint32_t tv_modulator_cntl1, tv_modulator_cntl2;
uint32_t tv_vscaler_cntl1, tv_vscaler_cntl2;
- uint32_t tv_pll_cntl, tv_pll_cntl1, tv_ftotal;
+ uint32_t tv_pll_cntl, tv_ftotal;
uint32_t tv_y_fall_cntl, tv_y_rise_cntl, tv_y_saw_tooth_cntl;
uint32_t m, n, p;
const uint16_t *hor_timing;
@@ -716,12 +716,6 @@ void radeon_legacy_tv_mode_set(struct drm_encoder *encoder,
(((n >> 9) & RADEON_TV_N0HI_MASK) << RADEON_TV_N0HI_SHIFT) |
((p & RADEON_TV_P_MASK) << RADEON_TV_P_SHIFT);
- tv_pll_cntl1 = (((4 & RADEON_TVPCP_MASK) << RADEON_TVPCP_SHIFT) |
- ((4 & RADEON_TVPVG_MASK) << RADEON_TVPVG_SHIFT) |
- ((1 & RADEON_TVPDC_MASK) << RADEON_TVPDC_SHIFT) |
- RADEON_TVCLK_SRC_SEL_TVPLL |
- RADEON_TVPLL_TEST_DIS);
-
tv_dac->tv.tv_uv_adr = 0xc8;
if (tv_dac->tv_std == TV_STD_NTSC ||
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.4 024/100] drm/amdgpu: remove always false comparison in 'amdgpu_atombios_i2c_process_i2c_ch'
From: yu kuai
[ Upstream commit 220ac8d1444054ade07ce14498fcda266410f90e ]
Fixes gcc '-Wtype-limits' warning:
drivers/gpu/drm/amd/amdgpu/atombios_i2c.c: In function
‘amdgpu_atombios_i2c_process_i2c_ch’:
drivers/gpu/drm/amd/amdgpu/atombios_i2c.c:79:11: warning: comparison is
always false due to limited range of data type [-Wtype-limits]
'num' is 'u8', so it will never be greater than 'TOM_MAX_HW_I2C_READ',
which is defined as 255. Therefore, the comparison can be removed.
Fixes: d38ceaf99ed0 ("drm/amdgpu: add core driver (v4)")
Signed-off-by: yu kuai
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdgpu/atombios_i2c.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/atombios_i2c.c
b/drivers/gpu/drm/amd/amdgpu/atombios_i2c.c
index 13cdb01e9b450..59fd674128540 100644
--- a/drivers/gpu/drm/amd/amdgpu/atombios_i2c.c
+++ b/drivers/gpu/drm/amd/amdgpu/atombios_i2c.c
@@ -68,11 +68,6 @@ static int amdgpu_atombios_i2c_process_i2c_ch(struct
amdgpu_i2c_chan *chan,
memcpy(, [1], num);
args.lpI2CDataOut = cpu_to_le16(out);
} else {
- if (num > ATOM_MAX_HW_I2C_READ) {
- DRM_ERROR("hw i2c: tried to read too many bytes (%d vs
255)\n", num);
- r = -EINVAL;
- goto done;
- }
args.ucRegIndex = 0;
args.lpI2CDataOut = 0;
}
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.4 030/100] drm/gma500: remove set but not used variable 'channel_eq'
From: zhengbin
[ Upstream commit a7adabeece570b8a566dd592219410456676796e ]
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/gma500/cdv_intel_dp.c: In function
cdv_intel_dp_complete_link_train:
drivers/gpu/drm/gma500/cdv_intel_dp.c:1596:7: warning: variable channel_eq set
but not used [-Wunused-but-set-variable]
It is never used, so remove it.
Reported-by: Hulk Robot
Signed-off-by: zhengbin
Signed-off-by: Daniel Vetter
Link:
https://patchwork.freedesktop.org/patch/msgid/1573902268-117518-1-git-send-email-zhengbi...@huawei.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/gma500/cdv_intel_dp.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/gma500/cdv_intel_dp.c
b/drivers/gpu/drm/gma500/cdv_intel_dp.c
index d3de377dc857e..107a63a11a0f9 100644
--- a/drivers/gpu/drm/gma500/cdv_intel_dp.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_dp.c
@@ -1593,7 +1593,6 @@ cdv_intel_dp_complete_link_train(struct gma_encoder
*encoder)
{
struct drm_device *dev = encoder->base.dev;
struct cdv_intel_dp *intel_dp = encoder->dev_priv;
- bool channel_eq = false;
int tries, cr_tries;
u32 reg;
uint32_t DP = intel_dp->DP;
@@ -1601,7 +1600,6 @@ cdv_intel_dp_complete_link_train(struct gma_encoder
*encoder)
/* channel equalization */
tries = 0;
cr_tries = 0;
- channel_eq = false;
DRM_DEBUG_KMS("\n");
reg = DP | DP_LINK_TRAIN_PAT_2;
@@ -1647,7 +1645,6 @@ cdv_intel_dp_complete_link_train(struct gma_encoder
*encoder)
if (cdv_intel_channel_eq_ok(encoder)) {
DRM_DEBUG_KMS("PT2 train is done\n");
- channel_eq = true;
break;
}
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.4 029/100] drm/gma500: remove set but not used variable 'is_hdmi', 'is_crt'
From: zhengbin
[ Upstream commit 834c43a97f341d319aa7b74099bbce2c4e75bc72 ]
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/gma500/cdv_intel_display.c: In function cdv_intel_crtc_mode_set:
drivers/gpu/drm/gma500/cdv_intel_display.c:594:7: warning: variable is_hdmi set
but not used [-Wunused-but-set-variable]
drivers/gpu/drm/gma500/cdv_intel_display.c: In function cdv_intel_crtc_mode_set:
drivers/gpu/drm/gma500/cdv_intel_display.c:593:7: warning: variable is_crt set
but not used [-Wunused-but-set-variable]
They are not used since commit acd7ef927e06 ("gma500:
Update the Cedarview clock handling")
Reported-by: Hulk Robot
Signed-off-by: zhengbin
Signed-off-by: Daniel Vetter
Link:
https://patchwork.freedesktop.org/patch/msgid/1573828027-122323-4-git-send-email-zhengbi...@huawei.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/gma500/cdv_intel_display.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/gma500/cdv_intel_display.c
b/drivers/gpu/drm/gma500/cdv_intel_display.c
index 7d47b3d5cc0d0..52c2895f714ed 100644
--- a/drivers/gpu/drm/gma500/cdv_intel_display.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_display.c
@@ -590,8 +590,8 @@ static int cdv_intel_crtc_mode_set(struct drm_crtc *crtc,
struct gma_clock_t clock;
u32 dpll = 0, dspcntr, pipeconf;
bool ok;
- bool is_crt = false, is_lvds = false, is_tv = false;
- bool is_hdmi = false, is_dp = false;
+ bool is_lvds = false, is_tv = false;
+ bool is_dp = false;
struct drm_mode_config *mode_config = >mode_config;
struct drm_connector *connector;
const struct gma_limit_t *limit;
@@ -615,10 +615,7 @@ static int cdv_intel_crtc_mode_set(struct drm_crtc *crtc,
is_tv = true;
break;
case INTEL_OUTPUT_ANALOG:
- is_crt = true;
- break;
case INTEL_OUTPUT_HDMI:
- is_hdmi = true;
break;
case INTEL_OUTPUT_DISPLAYPORT:
is_dp = true;
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.4 021/100] drm/amdgpu: remove 4 set but not used variable in amdgpu_atombios_get_connector_info_from_object_table
From: yu kuai
[ Upstream commit bae028e3e521e8cb8caf2cc16a455ce4c55f2332 ]
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c: In function
'amdgpu_atombios_get_connector_info_from_object_table':
drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:376:26: warning: variable
'grph_obj_num' set but not used [-Wunused-but-set-variable]
drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:376:13: warning: variable
'grph_obj_id' set but not used [-Wunused-but-set-variable]
drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:341:37: warning: variable
'con_obj_type' set but not used [-Wunused-but-set-variable]
drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:341:24: warning: variable
'con_obj_num' set but not used [-Wunused-but-set-variable]
They are never used, so can be removed.
Fixes: d38ceaf99ed0 ("drm/amdgpu: add core driver (v4)")
Signed-off-by: yu kuai
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c | 19 ++-
1 file changed, 2 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c
index 3e90ddcbb24a7..d799927d3a5de 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c
@@ -319,17 +319,9 @@ bool
amdgpu_atombios_get_connector_info_from_object_table(struct amdgpu_device *
path_size += le16_to_cpu(path->usSize);
if (device_support & le16_to_cpu(path->usDeviceTag)) {
- uint8_t con_obj_id, con_obj_num, con_obj_type;
-
- con_obj_id =
+ uint8_t con_obj_id =
(le16_to_cpu(path->usConnObjectId) & OBJECT_ID_MASK)
>> OBJECT_ID_SHIFT;
- con_obj_num =
- (le16_to_cpu(path->usConnObjectId) & ENUM_ID_MASK)
- >> ENUM_ID_SHIFT;
- con_obj_type =
- (le16_to_cpu(path->usConnObjectId) &
-OBJECT_TYPE_MASK) >> OBJECT_TYPE_SHIFT;
/* Skip TV/CV support */
if ((le16_to_cpu(path->usDeviceTag) ==
@@ -354,14 +346,7 @@ bool
amdgpu_atombios_get_connector_info_from_object_table(struct amdgpu_device *
router.ddc_valid = false;
router.cd_valid = false;
for (j = 0; j < ((le16_to_cpu(path->usSize) - 8) / 2);
j++) {
- uint8_t grph_obj_id, grph_obj_num,
grph_obj_type;
-
- grph_obj_id =
- (le16_to_cpu(path->usGraphicObjIds[j]) &
-OBJECT_ID_MASK) >> OBJECT_ID_SHIFT;
- grph_obj_num =
- (le16_to_cpu(path->usGraphicObjIds[j]) &
-ENUM_ID_MASK) >> ENUM_ID_SHIFT;
+ uint8_t grph_obj_type=
grph_obj_type =
(le16_to_cpu(path->usGraphicObjIds[j]) &
OBJECT_TYPE_MASK) >> OBJECT_TYPE_SHIFT;
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.4 026/100] drm/amdgpu: remove set but not used variable 'amdgpu_connector'
From: yu kuai
[ Upstream commit 4f2922d12d6c63d0f4aa4e859ad95aee6d0d4ea0 ]
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c: In function
‘amdgpu_display_crtc_scaling_mode_fixup’:
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c:693:27: warning: variable
‘amdgpu_connector’ set but not used [-Wunused-but-set-variable]
Fixes: d38ceaf99ed0 ("drm/amdgpu: add core driver (v4)")
Signed-off-by: yu kuai
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
index c555781685ea8..8b3a33ae44ed8 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
@@ -693,7 +693,6 @@ bool amdgpu_crtc_scaling_mode_fixup(struct drm_crtc *crtc,
struct amdgpu_crtc *amdgpu_crtc = to_amdgpu_crtc(crtc);
struct amdgpu_encoder *amdgpu_encoder;
struct drm_connector *connector;
- struct amdgpu_connector *amdgpu_connector;
u32 src_v = 1, dst_v = 1;
u32 src_h = 1, dst_h = 1;
@@ -705,7 +704,6 @@ bool amdgpu_crtc_scaling_mode_fixup(struct drm_crtc *crtc,
continue;
amdgpu_encoder = to_amdgpu_encoder(encoder);
connector = amdgpu_get_connector_for_encoder(encoder);
- amdgpu_connector = to_amdgpu_connector(connector);
/* set scaling */
if (amdgpu_encoder->rmx_type == RMX_OFF)
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.4 027/100] drm/gma500: remove set but not used variable 'htotal'
From: zhengbin
[ Upstream commit dfa703b6f91818fa9f652c00e3589c104c518930 ]
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/gma500/oaktrail_hdmi.c: In function htotal_calculate:
drivers/gpu/drm/gma500/oaktrail_hdmi.c:160:6: warning: variable htotal set but
not used [-Wunused-but-set-variable]
It is introduced by commit 39ec748f7174 ("gma600: Enable HDMI support"),
but never used, so remove it.
Reported-by: Hulk Robot
Signed-off-by: zhengbin
Signed-off-by: Daniel Vetter
Link:
https://patchwork.freedesktop.org/patch/msgid/1573828027-122323-2-git-send-email-zhengbi...@huawei.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/gma500/oaktrail_hdmi.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/gma500/oaktrail_hdmi.c
b/drivers/gpu/drm/gma500/oaktrail_hdmi.c
index 2310d879cdc2d..d5d30ce1159d1 100644
--- a/drivers/gpu/drm/gma500/oaktrail_hdmi.c
+++ b/drivers/gpu/drm/gma500/oaktrail_hdmi.c
@@ -157,9 +157,7 @@ static void oaktrail_hdmi_audio_disable(struct drm_device
*dev)
static unsigned int htotal_calculate(struct drm_display_mode *mode)
{
- u32 htotal, new_crtc_htotal;
-
- htotal = (mode->crtc_hdisplay - 1) | ((mode->crtc_htotal - 1) << 16);
+ u32 new_crtc_htotal;
/*
* 1024 x 768 new_crtc_htotal = 0x1024;
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.4 031/100] drm/radeon: remove set but not used variable 'size', 'relocs_chunk'
From: zhengbin
[ Upstream commit e9f782dd22c0e17874b8b8e12aafcd3a06810dd0 ]
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/radeon/r600_cs.c: In function r600_cs_track_validate_cb:
drivers/gpu/drm/radeon/r600_cs.c:353:22: warning: variable size set but not
used [-Wunused-but-set-variable]
drivers/gpu/drm/radeon/r600_cs.c: In function r600_cs_track_validate_db:
drivers/gpu/drm/radeon/r600_cs.c:520:27: warning: variable size set but not
used [-Wunused-but-set-variable]
drivers/gpu/drm/radeon/r600_cs.c: In function r600_dma_cs_next_reloc:
drivers/gpu/drm/radeon/r600_cs.c:2345:26: warning: variable relocs_chunk set
but not used [-Wunused-but-set-variable]
The first 'size' is not used since commit f30df2fad0c9 ("drm/radeon/r600:
fix tiling issues in CS checker.")
The second 'size' is introduced by commit 88f50c80748b ("drm/radeon/kms:
add htile support to the cs checker v3"), but never used, so remove it.
'relocs_chunk' is not used since commit 9305ede6afe2 ("radeon/kms:
fix dma relocation checking")
Reported-by: Hulk Robot
Signed-off-by: zhengbin
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/radeon/r600_cs.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r600_cs.c b/drivers/gpu/drm/radeon/r600_cs.c
index acc1f99c84d99..5a0e751dbe962 100644
--- a/drivers/gpu/drm/radeon/r600_cs.c
+++ b/drivers/gpu/drm/radeon/r600_cs.c
@@ -349,7 +349,7 @@ static void r600_cs_track_init(struct r600_cs_track *track)
static int r600_cs_track_validate_cb(struct radeon_cs_parser *p, int i)
{
struct r600_cs_track *track = p->track;
- u32 slice_tile_max, size, tmp;
+ u32 slice_tile_max, tmp;
u32 height, height_align, pitch, pitch_align, depth_align;
u64 base_offset, base_align;
struct array_mode_checker array_check;
@@ -359,7 +359,6 @@ static int r600_cs_track_validate_cb(struct
radeon_cs_parser *p, int i)
/* When resolve is used, the second colorbuffer has always 1 sample. */
unsigned nsamples = track->is_resolve && i == 1 ? 1 : track->nsamples;
- size = radeon_bo_size(track->cb_color_bo[i]) -
track->cb_color_bo_offset[i];
format = G_0280A0_FORMAT(track->cb_color_info[i]);
if (!r600_fmt_is_valid_color(format)) {
dev_warn(p->dev, "%s:%d cb invalid format %d for %d (0x%08X)\n",
@@ -516,7 +515,7 @@ static int r600_cs_track_validate_cb(struct
radeon_cs_parser *p, int i)
static int r600_cs_track_validate_db(struct radeon_cs_parser *p)
{
struct r600_cs_track *track = p->track;
- u32 nviews, bpe, ntiles, size, slice_tile_max, tmp;
+ u32 nviews, bpe, ntiles, slice_tile_max, tmp;
u32 height_align, pitch_align, depth_align;
u32 pitch = 8192;
u32 height = 8192;
@@ -563,7 +562,6 @@ static int r600_cs_track_validate_db(struct
radeon_cs_parser *p)
}
ib[track->db_depth_size_idx] = S_028000_SLICE_TILE_MAX(tmp - 1)
| (track->db_depth_size & 0x3FF);
} else {
- size = radeon_bo_size(track->db_bo);
/* pitch in pixels */
pitch = (G_028000_PITCH_TILE_MAX(track->db_depth_size) + 1) * 8;
slice_tile_max = G_028000_SLICE_TILE_MAX(track->db_depth_size)
+ 1;
@@ -2437,7 +2435,6 @@ void r600_cs_legacy_init(void)
int r600_dma_cs_next_reloc(struct radeon_cs_parser *p,
struct radeon_bo_list **cs_reloc)
{
- struct radeon_cs_chunk *relocs_chunk;
unsigned idx;
*cs_reloc = NULL;
@@ -2445,7 +2442,6 @@ int r600_dma_cs_next_reloc(struct radeon_cs_parser *p,
DRM_ERROR("No relocation chunk !\n");
return -EINVAL;
}
- relocs_chunk = p->chunk_relocs;
idx = p->dma_reloc_idx;
if (idx >= p->nrelocs) {
DRM_ERROR("Relocs at %d after relocations chunk end %d !\n",
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.4 025/100] drm/amdgpu: remove set but not used variable 'mc_shared_chmap'
From: yu kuai
[ Upstream commit e98042db2cb8d0b728cd76e05b9c2e1c84b7f72b ]
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c: In function
‘gfx_v8_0_gpu_early_init’:
drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c:1713:6: warning: variable
‘mc_shared_chmap’ set but not used [-Wunused-but-set-variable]
Fixes: 0bde3a95eaa9 ("drm/amdgpu: split gfx8 gpu init into sw and hw parts")
Signed-off-by: yu kuai
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
index d1054034d14b1..65d0a3e4f1f00 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
@@ -967,7 +967,7 @@ static int gfx_v8_0_mec_init(struct amdgpu_device *adev)
static void gfx_v8_0_gpu_early_init(struct amdgpu_device *adev)
{
u32 gb_addr_config;
- u32 mc_shared_chmap, mc_arb_ramcfg;
+ u32 mc_arb_ramcfg;
u32 dimm00_addr_map, dimm01_addr_map, dimm10_addr_map, dimm11_addr_map;
u32 tmp;
@@ -1131,7 +1131,6 @@ static void gfx_v8_0_gpu_early_init(struct amdgpu_device
*adev)
break;
}
- mc_shared_chmap = RREG32(mmMC_SHARED_CHMAP);
adev->gfx.config.mc_arb_ramcfg = RREG32(mmMC_ARB_RAMCFG);
mc_arb_ramcfg = adev->gfx.config.mc_arb_ramcfg;
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.4 023/100] drm/amdgpu: remove set but not used variable 'dig'
From: yu kuai
[ Upstream commit d1d09dc417826f5a983e0f4f212f227beeb65e29 ]
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/amd/amdgpu/atombios_dp.c: In function
‘amdgpu_atombios_dp_link_train’:
drivers/gpu/drm/amd/amdgpu/atombios_dp.c:716:34: warning: variable ‘dig’
set but not used [-Wunused-but-set-variable]
Fixes: d38ceaf99ed0 ("drm/amdgpu: add core driver (v4)")
Signed-off-by: yu kuai
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdgpu/atombios_dp.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
b/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
index 120a5fd992081..5448127daf27c 100644
--- a/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
+++ b/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
@@ -712,7 +712,6 @@ void amdgpu_atombios_dp_link_train(struct drm_encoder
*encoder,
struct drm_device *dev = encoder->dev;
struct amdgpu_device *adev = dev->dev_private;
struct amdgpu_encoder *amdgpu_encoder = to_amdgpu_encoder(encoder);
- struct amdgpu_encoder_atom_dig *dig;
struct amdgpu_connector *amdgpu_connector;
struct amdgpu_connector_atom_dig *dig_connector;
struct amdgpu_atombios_dp_link_train_info dp_info;
@@ -720,7 +719,6 @@ void amdgpu_atombios_dp_link_train(struct drm_encoder
*encoder,
if (!amdgpu_encoder->enc_priv)
return;
- dig = amdgpu_encoder->enc_priv;
amdgpu_connector = to_amdgpu_connector(connector);
if (!amdgpu_connector->con_priv)
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.4 033/100] drm/radeon: remove set but not used variable 'radeon_connector'
From: zhengbin
[ Upstream commit 5952c48993375a9da2de39be30df475cf590b0ce ]
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/radeon/radeon_display.c: In function
radeon_crtc_scaling_mode_fixup:
drivers/gpu/drm/radeon/radeon_display.c:1685:27: warning: variable
radeon_connector set but not used [-Wunused-but-set-variable]
It is not used since commit 377bd8a98d7d ("drm/radeon:
use a fetch function to get the edid")
Reported-by: Hulk Robot
Signed-off-by: zhengbin
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/radeon/radeon_display.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_display.c
b/drivers/gpu/drm/radeon/radeon_display.c
index 446d990623069..b26e4eae7ac54 100644
--- a/drivers/gpu/drm/radeon/radeon_display.c
+++ b/drivers/gpu/drm/radeon/radeon_display.c
@@ -1736,7 +1736,6 @@ bool radeon_crtc_scaling_mode_fixup(struct drm_crtc *crtc,
struct radeon_crtc *radeon_crtc = to_radeon_crtc(crtc);
struct radeon_encoder *radeon_encoder;
struct drm_connector *connector;
- struct radeon_connector *radeon_connector;
bool first = true;
u32 src_v = 1, dst_v = 1;
u32 src_h = 1, dst_h = 1;
@@ -1749,7 +1748,6 @@ bool radeon_crtc_scaling_mode_fixup(struct drm_crtc *crtc,
continue;
radeon_encoder = to_radeon_encoder(encoder);
connector = radeon_get_connector_for_encoder(encoder);
- radeon_connector = to_radeon_connector(connector);
if (first) {
/* set scaling */
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.4 028/100] drm/gma500: remove set but not used variable 'error'
From: zhengbin
[ Upstream commit a5eb29a9d2fc03d07af7d02f6c2e7ae1e6d985f9 ]
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/gma500/psb_irq.c: In function psb_sgx_interrupt:
drivers/gpu/drm/gma500/psb_irq.c:210:6: warning: variable error set but not
used [-Wunused-but-set-variable]
It is introduced by commit 64a4aff283ac ("drm/gma500:
Add support for SGX interrupts"), but never used, so remove it.
Reported-by: Hulk Robot
Signed-off-by: zhengbin
Signed-off-by: Daniel Vetter
Link:
https://patchwork.freedesktop.org/patch/msgid/1573828027-122323-3-git-send-email-zhengbi...@huawei.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/gma500/psb_irq.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/gma500/psb_irq.c b/drivers/gpu/drm/gma500/psb_irq.c
index 78eb109028091..f75f199c84311 100644
--- a/drivers/gpu/drm/gma500/psb_irq.c
+++ b/drivers/gpu/drm/gma500/psb_irq.c
@@ -207,7 +207,6 @@ static void psb_sgx_interrupt(struct drm_device *dev, u32
stat_1, u32 stat_2)
{
struct drm_psb_private *dev_priv = dev->dev_private;
u32 val, addr;
- int error = false;
if (stat_1 & _PSB_CE_TWOD_COMPLETE)
val = PSB_RSGX32(PSB_CR_2D_BLIT_STATUS);
@@ -242,7 +241,6 @@ static void psb_sgx_interrupt(struct drm_device *dev, u32
stat_1, u32 stat_2)
DRM_ERROR("\tMMU failing address is 0x%08x.\n",
(unsigned int)addr);
- error = true;
}
}
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.4 001/100] drm/gma500: Fixup fbdev stolen size usage evaluation
From: Paul Kocialkowski
[ Upstream commit fd1a5e521c3c083bb43ea731aae0f8b95f12b9bd ]
psbfb_probe performs an evaluation of the required size from the stolen
GTT memory, but gets it wrong in two distinct ways:
- The resulting size must be page-size-aligned;
- The size to allocate is derived from the surface dimensions, not the fb
dimensions.
When two connectors are connected with different modes, the smallest will
be stored in the fb dimensions, but the size that needs to be allocated must
match the largest (surface) dimensions. This is what is used in the actual
allocation code.
Fix this by correcting the evaluation to conform to the two points above.
It allows correctly switching to 16bpp when one connector is e.g. 1920x1080
and the other is 1024x768.
Signed-off-by: Paul Kocialkowski
Signed-off-by: Patrik Jakobsson
Link:
https://patchwork.freedesktop.org/patch/msgid/20191107153048.843881-1-paul.kocialkow...@bootlin.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/gma500/framebuffer.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/gma500/framebuffer.c
b/drivers/gpu/drm/gma500/framebuffer.c
index 2eaf1b31c7bd8..ef60bb1971951 100644
--- a/drivers/gpu/drm/gma500/framebuffer.c
+++ b/drivers/gpu/drm/gma500/framebuffer.c
@@ -533,6 +533,7 @@ static int psbfb_probe(struct drm_fb_helper *helper,
container_of(helper, struct psb_fbdev, psb_fb_helper);
struct drm_device *dev = psb_fbdev->psb_fb_helper.dev;
struct drm_psb_private *dev_priv = dev->dev_private;
+ unsigned int fb_size;
int bytespp;
bytespp = sizes->surface_bpp / 8;
@@ -542,8 +543,11 @@ static int psbfb_probe(struct drm_fb_helper *helper,
/* If the mode will not fit in 32bit then switch to 16bit to get
a console on full resolution. The X mode setting server will
allocate its own 32bit GEM framebuffer */
- if (ALIGN(sizes->fb_width * bytespp, 64) * sizes->fb_height >
- dev_priv->vram_stolen_size) {
+ fb_size = ALIGN(sizes->surface_width * bytespp, 64) *
+ sizes->surface_height;
+ fb_size = ALIGN(fb_size, PAGE_SIZE);
+
+ if (fb_size > dev_priv->vram_stolen_size) {
sizes->surface_bpp = 16;
sizes->surface_depth = 16;
}
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.9 131/141] radeon: insert 10ms sleep in dce5_crtc_load_lut
From: Daniel Vetter
[ Upstream commit ec3d65082d7dabad6fa8f66a8ef166f2d522d6b2 ]
Per at least one tester this is enough magic to recover the regression
introduced for some people (but not all) in
commit b8e2b0199cc377617dc238f5106352c06dcd3fa2
Author: Peter Rosin
Date: Tue Jul 4 12:36:57 2017 +0200
drm/fb-helper: factor out pseudo-palette
which for radeon had the side-effect of refactoring out a seemingly
redudant writing of the color palette.
10ms in a fairly slow modeset path feels like an acceptable form of
duct-tape, so maybe worth a shot and see what sticks.
Cc: Alex Deucher
Cc: Michel Dänzer
References: https://bugzilla.kernel.org/show_bug.cgi?id=198123
Signed-off-by: Daniel Vetter
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/radeon/radeon_display.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/radeon/radeon_display.c
b/drivers/gpu/drm/radeon/radeon_display.c
index 59d62275a659d..c8820cd893d49 100644
--- a/drivers/gpu/drm/radeon/radeon_display.c
+++ b/drivers/gpu/drm/radeon/radeon_display.c
@@ -110,6 +110,8 @@ static void dce5_crtc_load_lut(struct drm_crtc *crtc)
DRM_DEBUG_KMS("%d\n", radeon_crtc->crtc_id);
+ msleep(10);
+
WREG32(NI_INPUT_CSC_CONTROL + radeon_crtc->crtc_offset,
(NI_INPUT_CSC_GRPH_MODE(NI_INPUT_CSC_BYPASS) |
NI_INPUT_CSC_OVL_MODE(NI_INPUT_CSC_BYPASS)));
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.9 127/141] drm/nouveau/disp/nv50-: prevent oops when no channel method map provided
From: Ben Skeggs
[ Upstream commit 0e6176c6d286316e9431b4f695940cfac4ffe6c2 ]
The implementations for most channel types contains a map of methods to
priv registers in order to provide debugging info when a disp exception
has been raised.
This info is missing from the implementation of PIO channels as they're
rather simplistic already, however, if an exception is raised by one of
them, we'd end up triggering a NULL-pointer deref. Not ideal...
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=206299
Signed-off-by: Ben Skeggs
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/nouveau/nvkm/engine/disp/channv50.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/disp/channv50.c
b/drivers/gpu/drm/nouveau/nvkm/engine/disp/channv50.c
index 9d90d8b4b7e65..f5a8db1bb8b72 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/disp/channv50.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/disp/channv50.c
@@ -72,6 +72,8 @@ nv50_disp_chan_mthd(struct nv50_disp_chan *chan, int debug)
if (debug > subdev->debug)
return;
+ if (!mthd)
+ return;
for (i = 0; (list = mthd->data[i].mthd) != NULL; i++) {
u32 base = chan->head * mthd->addr;
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.9 099/141] drm/nouveau: Fix copy-paste error in nouveau_fence_wait_uevent_handler
From: YueHaibing
[ Upstream commit 1eb013473bff5f95b6fe1ca4dd7deda47257b9c2 ]
Like other cases, it should use rcu protected 'chan' rather
than 'fence->channel' in nouveau_fence_wait_uevent_handler.
Fixes: 0ec5f02f0e2c ("drm/nouveau: prevent stale fence->channel pointers, and
protect with rcu")
Signed-off-by: YueHaibing
Signed-off-by: Ben Skeggs
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/nouveau/nouveau_fence.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c
b/drivers/gpu/drm/nouveau/nouveau_fence.c
index 4bb9ab892ae19..78e521d00251c 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fence.c
+++ b/drivers/gpu/drm/nouveau/nouveau_fence.c
@@ -158,7 +158,7 @@ nouveau_fence_wait_uevent_handler(struct nvif_notify
*notify)
fence = list_entry(fctx->pending.next, typeof(*fence), head);
chan = rcu_dereference_protected(fence->channel,
lockdep_is_held(>lock));
- if (nouveau_fence_update(fence->channel, fctx))
+ if (nouveau_fence_update(chan, fctx))
ret = NVIF_NOTIFY_DROP;
}
spin_unlock_irqrestore(>lock, flags);
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.9 098/141] drm/nouveau/gr/gk20a, gm200-: add terminators to method lists read from fw
From: Ben Skeggs
[ Upstream commit 7adc77aa0e11f25b0e762859219c70852cd8d56f ]
Method init is typically ordered by class in the FW image as ThreeD,
TwoD, Compute.
Due to a bug in parsing the FW into our internal format, we've been
accidentally sending Twod + Compute methods to the ThreeD class, as
well as Compute methods to the TwoD class - oops.
Signed-off-by: Ben Skeggs
Signed-off-by: Sasha Levin
---
.../gpu/drm/nouveau/nvkm/engine/gr/gk20a.c| 21 ++-
1 file changed, 11 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/gr/gk20a.c
b/drivers/gpu/drm/nouveau/nvkm/engine/gr/gk20a.c
index de8b806b88fd9..7618b2eb4fdfd 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/gr/gk20a.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/gr/gk20a.c
@@ -143,23 +143,24 @@ gk20a_gr_av_to_method(struct gf100_gr *gr, const char
*fw_name,
nent = (fuc.size / sizeof(struct gk20a_fw_av));
- pack = vzalloc((sizeof(*pack) * max_classes) +
- (sizeof(*init) * (nent + 1)));
+ pack = vzalloc((sizeof(*pack) * (max_classes + 1)) +
+ (sizeof(*init) * (nent + max_classes + 1)));
if (!pack) {
ret = -ENOMEM;
goto end;
}
- init = (void *)(pack + max_classes);
+ init = (void *)(pack + max_classes + 1);
- for (i = 0; i < nent; i++) {
- struct gf100_gr_init *ent = [i];
+ for (i = 0; i < nent; i++, init++) {
struct gk20a_fw_av *av = &((struct gk20a_fw_av *)fuc.data)[i];
u32 class = av->addr & 0x;
u32 addr = (av->addr & 0x) >> 14;
if (prevclass != class) {
- pack[classidx].init = ent;
+ if (prevclass) /* Add terminator to the method list. */
+ init++;
+ pack[classidx].init = init;
pack[classidx].type = class;
prevclass = class;
if (++classidx >= max_classes) {
@@ -169,10 +170,10 @@ gk20a_gr_av_to_method(struct gf100_gr *gr, const char
*fw_name,
}
}
- ent->addr = addr;
- ent->data = av->data;
- ent->count = 1;
- ent->pitch = 1;
+ init->addr = addr;
+ init->data = av->data;
+ init->count = 1;
+ init->pitch = 1;
}
*ppack = pack;
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.9 100/141] drm/vmwgfx: prevent memory leak in vmw_cmdbuf_res_add
From: Navid Emamdoost
[ Upstream commit 40efb09a7f53125719e49864da008495e39aaa1e ]
In vmw_cmdbuf_res_add if drm_ht_insert_item fails the allocated memory
for cres should be released.
Fixes: 18e4a4669c50 ("drm/vmwgfx: Fix compat shader namespace")
Signed-off-by: Navid Emamdoost
Reviewed-by: Thomas Hellstrom
Signed-off-by: Thomas Hellstrom
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf_res.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf_res.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf_res.c
index 1f013d45c9e9a..0c7c3005594cc 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf_res.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf_res.c
@@ -210,8 +210,10 @@ int vmw_cmdbuf_res_add(struct vmw_cmdbuf_res_manager *man,
cres->hash.key = user_key | (res_type << 24);
ret = drm_ht_insert_item(>resources, >hash);
- if (unlikely(ret != 0))
+ if (unlikely(ret != 0)) {
+ kfree(cres);
goto out_invalid_key;
+ }
cres->state = VMW_CMDBUF_RES_ADD;
cres->res = vmw_resource_reference(res);
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.9 069/141] drm/mediatek: handle events when enabling/disabling crtc
From: Bibby Hsieh
[ Upstream commit 411f5c1eacfebb1f6e40b653d29447cdfe7282aa ]
The driver currently handles vblank events only when updating planes on
an already enabled CRTC. The atomic update API however allows requesting
an event when enabling or disabling a CRTC. This currently leads to
event objects being leaked in the kernel and to events not being sent
out. Fix it.
Signed-off-by: Bibby Hsieh
Signed-off-by: CK Hu
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index 01a21dd835b57..1ed60da76a0ce 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -306,6 +306,7 @@ static int mtk_crtc_ddp_hw_init(struct mtk_drm_crtc
*mtk_crtc)
static void mtk_crtc_ddp_hw_fini(struct mtk_drm_crtc *mtk_crtc)
{
struct drm_device *drm = mtk_crtc->base.dev;
+ struct drm_crtc *crtc = _crtc->base;
int i;
DRM_DEBUG_DRIVER("%s\n", __func__);
@@ -327,6 +328,13 @@ static void mtk_crtc_ddp_hw_fini(struct mtk_drm_crtc
*mtk_crtc)
mtk_disp_mutex_unprepare(mtk_crtc->mutex);
pm_runtime_put(drm->dev);
+
+ if (crtc->state->event && !crtc->state->active) {
+ spin_lock_irq(>dev->event_lock);
+ drm_crtc_send_vblank_event(crtc, crtc->state->event);
+ crtc->state->event = NULL;
+ spin_unlock_irq(>dev->event_lock);
+ }
}
static void mtk_drm_crtc_enable(struct drm_crtc *crtc)
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH AUTOSEL 5.5 408/542] drm/amdgpu: add the lost mutex_init back
On Fri, Feb 14, 2020 at 10:57 AM Sasha Levin wrote: > > From: "Pan, Xinhui" > > [ Upstream commit bd0522112332663e386df1b8642052463ea9b3b9 ] > > Initialize notifier_lock. > > Bug: https://gitlab.freedesktop.org/drm/amd/issues/1016 > Reviewed-by: Feifei Xu > Reviewed-by: Christian König > Signed-off-by: xinhui pan > Signed-off-by: Alex Deucher > Signed-off-by: Sasha Levin > --- > drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c > b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c > index 332b9c24a2cd0..a2f788ad7e1c6 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c > @@ -2797,6 +2797,7 @@ int amdgpu_device_init(struct amdgpu_device *adev, > mutex_init(>notifier_lock); > mutex_init(>virt.dpm_mutex); > mutex_init(>psp.mutex); > + mutex_init(>notifier_lock); > This patch is not relevant here. The same mutex is already initialized 3 lines above. Alex > r = amdgpu_device_check_arguments(adev); > if (r) > -- > 2.20.1 > > ___ > amd-gfx mailing list > amd-...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/amd-gfx ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.9 080/141] drm/gma500: remove set but not used variables 'hist_reg'
From: Chen Zhou
[ Upstream commit 72f775611daf3ce20358388facbaf11f22899fa2 ]
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/gma500/psb_irq.c: In function psb_irq_turn_off_dpst:
drivers/gpu/drm/gma500/psb_irq.c:473:6:
warning: variable hist_reg set but not used [-Wunused-but-set-variable]
Reported-by: Hulk Robot
Signed-off-by: Chen Zhou
Signed-off-by: Patrik Jakobsson
Link:
https://patchwork.freedesktop.org/patch/msgid/20191227114811.14907-1-chenzho...@huawei.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/gma500/psb_irq.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/gma500/psb_irq.c b/drivers/gpu/drm/gma500/psb_irq.c
index f75f199c84311..518d7b4456bf1 100644
--- a/drivers/gpu/drm/gma500/psb_irq.c
+++ b/drivers/gpu/drm/gma500/psb_irq.c
@@ -471,12 +471,11 @@ void psb_irq_turn_off_dpst(struct drm_device *dev)
{
struct drm_psb_private *dev_priv =
(struct drm_psb_private *) dev->dev_private;
- u32 hist_reg;
u32 pwm_reg;
if (gma_power_begin(dev, false)) {
PSB_WVDC32(0x, HISTOGRAM_INT_CONTROL);
- hist_reg = PSB_RVDC32(HISTOGRAM_INT_CONTROL);
+ PSB_RVDC32(HISTOGRAM_INT_CONTROL);
psb_disable_pipestat(dev_priv, 0, PIPE_DPST_EVENT_ENABLE);
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.9 035/141] drm/amdgpu: remove always false comparison in 'amdgpu_atombios_i2c_process_i2c_ch'
From: yu kuai
[ Upstream commit 220ac8d1444054ade07ce14498fcda266410f90e ]
Fixes gcc '-Wtype-limits' warning:
drivers/gpu/drm/amd/amdgpu/atombios_i2c.c: In function
‘amdgpu_atombios_i2c_process_i2c_ch’:
drivers/gpu/drm/amd/amdgpu/atombios_i2c.c:79:11: warning: comparison is
always false due to limited range of data type [-Wtype-limits]
'num' is 'u8', so it will never be greater than 'TOM_MAX_HW_I2C_READ',
which is defined as 255. Therefore, the comparison can be removed.
Fixes: d38ceaf99ed0 ("drm/amdgpu: add core driver (v4)")
Signed-off-by: yu kuai
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdgpu/atombios_i2c.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/atombios_i2c.c
b/drivers/gpu/drm/amd/amdgpu/atombios_i2c.c
index b374653bd6cf3..741bd1e52699b 100644
--- a/drivers/gpu/drm/amd/amdgpu/atombios_i2c.c
+++ b/drivers/gpu/drm/amd/amdgpu/atombios_i2c.c
@@ -69,11 +69,6 @@ static int amdgpu_atombios_i2c_process_i2c_ch(struct
amdgpu_i2c_chan *chan,
memcpy(, [1], num);
args.lpI2CDataOut = cpu_to_le16(out);
} else {
- if (num > ATOM_MAX_HW_I2C_READ) {
- DRM_ERROR("hw i2c: tried to read too many bytes (%d vs
255)\n", num);
- r = -EINVAL;
- goto done;
- }
args.ucRegIndex = 0;
args.lpI2CDataOut = 0;
}
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.9 044/141] drm/radeon: remove set but not used variable 'dig_connector'
From: zhengbin
[ Upstream commit 3f47f0301594c4f930a32bd7d8125cfdeb6b4b6e ]
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/radeon/atombios_dp.c: In function radeon_dp_get_panel_mode:
drivers/gpu/drm/radeon/atombios_dp.c:415:36: warning: variable dig_connector
set but not used [-Wunused-but-set-variable]
It is not used since commit 379dfc25e257 ("drm/radeon/dp:
switch to the common i2c over aux code")
Reported-by: Hulk Robot
Signed-off-by: zhengbin
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/radeon/atombios_dp.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/radeon/atombios_dp.c
b/drivers/gpu/drm/radeon/atombios_dp.c
index fd7682bf335dc..b381fb17694b1 100644
--- a/drivers/gpu/drm/radeon/atombios_dp.c
+++ b/drivers/gpu/drm/radeon/atombios_dp.c
@@ -412,7 +412,6 @@ int radeon_dp_get_panel_mode(struct drm_encoder *encoder,
struct drm_device *dev = encoder->dev;
struct radeon_device *rdev = dev->dev_private;
struct radeon_connector *radeon_connector =
to_radeon_connector(connector);
- struct radeon_connector_atom_dig *dig_connector;
int panel_mode = DP_PANEL_MODE_EXTERNAL_DP_MODE;
u16 dp_bridge =
radeon_connector_encoder_get_dp_bridge_encoder_id(connector);
u8 tmp;
@@ -423,8 +422,6 @@ int radeon_dp_get_panel_mode(struct drm_encoder *encoder,
if (!radeon_connector->con_priv)
return panel_mode;
- dig_connector = radeon_connector->con_priv;
-
if (dp_bridge != ENCODER_OBJECT_ID_NONE) {
/* DP bridge chips */
if (drm_dp_dpcd_readb(_connector->ddc_bus->aux,
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.9 043/141] drm/radeon: remove set but not used variable 'backbias_response_time'
From: zhengbin
[ Upstream commit ac52caecbcf2c30ce95b2536c1caf2643c49b91c ]
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/radeon/si_dpm.c: In function si_program_response_times:
drivers/gpu/drm/radeon/si_dpm.c:3640:29: warning: variable
backbias_response_time set but not used [-Wunused-but-set-variable]
It is introduced by commit a9e61410921b ("drm/radeon/kms:
add dpm support for SI (v7)"), but never used, so remove it.
Reported-by: Hulk Robot
Signed-off-by: zhengbin
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/radeon/si_dpm.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/si_dpm.c b/drivers/gpu/drm/radeon/si_dpm.c
index ac7ae206f2e71..06c7244a1f9c5 100644
--- a/drivers/gpu/drm/radeon/si_dpm.c
+++ b/drivers/gpu/drm/radeon/si_dpm.c
@@ -3695,14 +3695,13 @@ static int si_notify_smc_display_change(struct
radeon_device *rdev,
static void si_program_response_times(struct radeon_device *rdev)
{
- u32 voltage_response_time, backbias_response_time, acpi_delay_time,
vbi_time_out;
+ u32 voltage_response_time, acpi_delay_time, vbi_time_out;
u32 vddc_dly, acpi_dly, vbi_dly;
u32 reference_clock;
si_write_smc_soft_register(rdev, SI_SMC_SOFT_REGISTER_mvdd_chg_time, 1);
voltage_response_time = (u32)rdev->pm.dpm.voltage_response_time;
- backbias_response_time = (u32)rdev->pm.dpm.backbias_response_time;
if (voltage_response_time == 0)
voltage_response_time = 1000;
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.9 046/141] drm/radeon: remove set but not used variable 'blocks'
From: zhengbin
[ Upstream commit 77441f77949807fda4a0aec0bdf3e86ae863fd56 ]
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/radeon/radeon_combios.c: In function
radeon_combios_get_power_modes:
drivers/gpu/drm/radeon/radeon_combios.c:2638:10: warning: variable blocks set
but not used [-Wunused-but-set-variable]
It is introduced by commit 56278a8edace ("drm/radeon/kms:
pull power mode info from bios tables (v3)"), but never used,
so remove it.
Reported-by: Hulk Robot
Signed-off-by: zhengbin
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/radeon/radeon_combios.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_combios.c
b/drivers/gpu/drm/radeon/radeon_combios.c
index 3178ba0c537c1..a01e52445ad11 100644
--- a/drivers/gpu/drm/radeon/radeon_combios.c
+++ b/drivers/gpu/drm/radeon/radeon_combios.c
@@ -2635,7 +2635,7 @@ void radeon_combios_get_power_modes(struct radeon_device
*rdev)
{
struct drm_device *dev = rdev->ddev;
u16 offset, misc, misc2 = 0;
- u8 rev, blocks, tmp;
+ u8 rev, tmp;
int state_index = 0;
struct radeon_i2c_bus_rec i2c_bus;
@@ -2725,7 +2725,6 @@ void radeon_combios_get_power_modes(struct radeon_device
*rdev)
offset = combios_get_table_offset(dev,
COMBIOS_POWERPLAY_INFO_TABLE);
if (offset) {
rev = RBIOS8(offset);
- blocks = RBIOS8(offset + 0x2);
/* power mode 0 tends to be the only valid one */
rdev->pm.power_state[state_index].num_clock_modes = 1;
rdev->pm.power_state[state_index].clock_info[0].mclk =
RBIOS32(offset + 0x5 + 0x2);
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.9 034/141] drm/amdgpu: remove set but not used variable 'dig'
From: yu kuai
[ Upstream commit d1d09dc417826f5a983e0f4f212f227beeb65e29 ]
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/amd/amdgpu/atombios_dp.c: In function
‘amdgpu_atombios_dp_link_train’:
drivers/gpu/drm/amd/amdgpu/atombios_dp.c:716:34: warning: variable ‘dig’
set but not used [-Wunused-but-set-variable]
Fixes: d38ceaf99ed0 ("drm/amdgpu: add core driver (v4)")
Signed-off-by: yu kuai
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdgpu/atombios_dp.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
b/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
index d712dee892545..8abe9beab0343 100644
--- a/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
+++ b/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
@@ -710,7 +710,6 @@ void amdgpu_atombios_dp_link_train(struct drm_encoder
*encoder,
struct drm_device *dev = encoder->dev;
struct amdgpu_device *adev = dev->dev_private;
struct amdgpu_encoder *amdgpu_encoder = to_amdgpu_encoder(encoder);
- struct amdgpu_encoder_atom_dig *dig;
struct amdgpu_connector *amdgpu_connector;
struct amdgpu_connector_atom_dig *dig_connector;
struct amdgpu_atombios_dp_link_train_info dp_info;
@@ -718,7 +717,6 @@ void amdgpu_atombios_dp_link_train(struct drm_encoder
*encoder,
if (!amdgpu_encoder->enc_priv)
return;
- dig = amdgpu_encoder->enc_priv;
amdgpu_connector = to_amdgpu_connector(connector);
if (!amdgpu_connector->con_priv)
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.9 036/141] drm/amdgpu: remove set but not used variable 'mc_shared_chmap'
From: yu kuai
[ Upstream commit e98042db2cb8d0b728cd76e05b9c2e1c84b7f72b ]
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c: In function
‘gfx_v8_0_gpu_early_init’:
drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c:1713:6: warning: variable
‘mc_shared_chmap’ set but not used [-Wunused-but-set-variable]
Fixes: 0bde3a95eaa9 ("drm/amdgpu: split gfx8 gpu init into sw and hw parts")
Signed-off-by: yu kuai
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
index c8a5cf5365a94..da32c7e49be0d 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
@@ -1739,7 +1739,7 @@ static int gfx_v8_0_do_edc_gpr_workarounds(struct
amdgpu_device *adev)
static int gfx_v8_0_gpu_early_init(struct amdgpu_device *adev)
{
u32 gb_addr_config;
- u32 mc_shared_chmap, mc_arb_ramcfg;
+ u32 mc_arb_ramcfg;
u32 dimm00_addr_map, dimm01_addr_map, dimm10_addr_map, dimm11_addr_map;
u32 tmp;
int ret;
@@ -1932,7 +1932,6 @@ static int gfx_v8_0_gpu_early_init(struct amdgpu_device
*adev)
break;
}
- mc_shared_chmap = RREG32(mmMC_SHARED_CHMAP);
adev->gfx.config.mc_arb_ramcfg = RREG32(mmMC_ARB_RAMCFG);
mc_arb_ramcfg = adev->gfx.config.mc_arb_ramcfg;
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.9 047/141] drm/radeon: remove set but not used variable 'tv_pll_cntl1'
From: zhengbin
[ Upstream commit dc9b3dbd28744510b78490dc6312848a8f918749 ]
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/radeon/radeon_legacy_tv.c: In function
radeon_legacy_tv_mode_set:
drivers/gpu/drm/radeon/radeon_legacy_tv.c:538:24: warning: variable
tv_pll_cntl1 set but not used [-Wunused-but-set-variable]
It is introduced by commit 4ce001abafaf ("drm/radeon/kms:
add initial radeon tv-out support."), but never used,
so remove it.
Reported-by: Hulk Robot
Signed-off-by: zhengbin
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/radeon/radeon_legacy_tv.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_legacy_tv.c
b/drivers/gpu/drm/radeon/radeon_legacy_tv.c
index 49750d07ab7d4..3133f5dfc239a 100644
--- a/drivers/gpu/drm/radeon/radeon_legacy_tv.c
+++ b/drivers/gpu/drm/radeon/radeon_legacy_tv.c
@@ -544,7 +544,7 @@ void radeon_legacy_tv_mode_set(struct drm_encoder *encoder,
uint32_t tv_master_cntl, tv_rgb_cntl, tv_dac_cntl;
uint32_t tv_modulator_cntl1, tv_modulator_cntl2;
uint32_t tv_vscaler_cntl1, tv_vscaler_cntl2;
- uint32_t tv_pll_cntl, tv_pll_cntl1, tv_ftotal;
+ uint32_t tv_pll_cntl, tv_ftotal;
uint32_t tv_y_fall_cntl, tv_y_rise_cntl, tv_y_saw_tooth_cntl;
uint32_t m, n, p;
const uint16_t *hor_timing;
@@ -716,12 +716,6 @@ void radeon_legacy_tv_mode_set(struct drm_encoder *encoder,
(((n >> 9) & RADEON_TV_N0HI_MASK) << RADEON_TV_N0HI_SHIFT) |
((p & RADEON_TV_P_MASK) << RADEON_TV_P_SHIFT);
- tv_pll_cntl1 = (((4 & RADEON_TVPCP_MASK) << RADEON_TVPCP_SHIFT) |
- ((4 & RADEON_TVPVG_MASK) << RADEON_TVPVG_SHIFT) |
- ((1 & RADEON_TVPDC_MASK) << RADEON_TVPDC_SHIFT) |
- RADEON_TVCLK_SRC_SEL_TVPLL |
- RADEON_TVPLL_TEST_DIS);
-
tv_dac->tv.tv_uv_adr = 0xc8;
if (tv_dac->tv_std == TV_STD_NTSC ||
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.9 041/141] drm/gma500: remove set but not used variable 'channel_eq'
From: zhengbin
[ Upstream commit a7adabeece570b8a566dd592219410456676796e ]
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/gma500/cdv_intel_dp.c: In function
cdv_intel_dp_complete_link_train:
drivers/gpu/drm/gma500/cdv_intel_dp.c:1596:7: warning: variable channel_eq set
but not used [-Wunused-but-set-variable]
It is never used, so remove it.
Reported-by: Hulk Robot
Signed-off-by: zhengbin
Signed-off-by: Daniel Vetter
Link:
https://patchwork.freedesktop.org/patch/msgid/1573902268-117518-1-git-send-email-zhengbi...@huawei.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/gma500/cdv_intel_dp.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/gma500/cdv_intel_dp.c
b/drivers/gpu/drm/gma500/cdv_intel_dp.c
index c52f9adf5e04c..af2cc63f3dcce 100644
--- a/drivers/gpu/drm/gma500/cdv_intel_dp.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_dp.c
@@ -1593,7 +1593,6 @@ cdv_intel_dp_complete_link_train(struct gma_encoder
*encoder)
{
struct drm_device *dev = encoder->base.dev;
struct cdv_intel_dp *intel_dp = encoder->dev_priv;
- bool channel_eq = false;
int tries, cr_tries;
u32 reg;
uint32_t DP = intel_dp->DP;
@@ -1601,7 +1600,6 @@ cdv_intel_dp_complete_link_train(struct gma_encoder
*encoder)
/* channel equalization */
tries = 0;
cr_tries = 0;
- channel_eq = false;
DRM_DEBUG_KMS("\n");
reg = DP | DP_LINK_TRAIN_PAT_2;
@@ -1647,7 +1645,6 @@ cdv_intel_dp_complete_link_train(struct gma_encoder
*encoder)
if (cdv_intel_channel_eq_ok(encoder)) {
DRM_DEBUG_KMS("PT2 train is done\n");
- channel_eq = true;
break;
}
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.9 045/141] drm/radeon: remove set but not used variable 'radeon_connector'
From: zhengbin
[ Upstream commit 5952c48993375a9da2de39be30df475cf590b0ce ]
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/radeon/radeon_display.c: In function
radeon_crtc_scaling_mode_fixup:
drivers/gpu/drm/radeon/radeon_display.c:1685:27: warning: variable
radeon_connector set but not used [-Wunused-but-set-variable]
It is not used since commit 377bd8a98d7d ("drm/radeon:
use a fetch function to get the edid")
Reported-by: Hulk Robot
Signed-off-by: zhengbin
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/radeon/radeon_display.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_display.c
b/drivers/gpu/drm/radeon/radeon_display.c
index 8b6f8aa238063..59d62275a659d 100644
--- a/drivers/gpu/drm/radeon/radeon_display.c
+++ b/drivers/gpu/drm/radeon/radeon_display.c
@@ -1719,7 +1719,6 @@ bool radeon_crtc_scaling_mode_fixup(struct drm_crtc *crtc,
struct radeon_crtc *radeon_crtc = to_radeon_crtc(crtc);
struct radeon_encoder *radeon_encoder;
struct drm_connector *connector;
- struct radeon_connector *radeon_connector;
bool first = true;
u32 src_v = 1, dst_v = 1;
u32 src_h = 1, dst_h = 1;
@@ -1732,7 +1731,6 @@ bool radeon_crtc_scaling_mode_fixup(struct drm_crtc *crtc,
continue;
radeon_encoder = to_radeon_encoder(encoder);
connector = radeon_get_connector_for_encoder(encoder);
- radeon_connector = to_radeon_connector(connector);
if (first) {
/* set scaling */
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7 01/13] dt-bindings: arm: move mmsys description to display
Hi, Matthias & Enric:
On Fri, 2020-02-14 at 13:19 +0100, Enric Balletbo i Serra wrote:
> Hi CK,
>
> On 14/2/20 11:01, Matthias Brugger wrote:
> >
> >
> > On 14/02/2020 07:42, CK Hu wrote:
> >> Hi, Matthias:
> >>
> >> On Thu, 2020-02-13 at 21:19 +0100, matthias@kernel.org wrote:
> >>> From: Matthias Brugger
> >>>
> >>> The mmsys block provides registers and clocks for the display
> >>> subsystem. The binding description should therefore live together with
> >>> the rest of the display descriptions. Move it to display/mediatek.
> >>>
> >>
> >> Yes, for the upstreamed driver, only display (DRM) use mmsys clock. For
> >> some MDP patches [1] in progress, MDP also use mmsys clock. So we just
> >> consider what's upstreamed now?
> >
>
> Let me jump into the discussion, and sorry if my question is silly because I'm
> just starting to look at this code.
>
> IMO we should consider all the cases to find a proper fix on all this, and if
> MDP uses also mmsys clocks this approach will not work. I think the main
> problem
> here and the big question is what exactly is the MMSYS block, is an
> independent
> clock controller that provides clocks to DRM and other blocks? or is hardly
> tied
> to the DRM block in some way?
>
> Could you give us a block schema on how the things are interconnected?
>
> If is an independent clock controller I think there was a mistake when the
> first
> drm driver was pushed by using the compatible = "mediatek,mt8173-mmsys" as id
> for that driver.
>
I correct my mistake first. In mt8173, mdp has already upstreamed [1].
There are many partitions in Mediatek SoC. mmsys is one of these
partition. There are many function blocks in mmsys such as OVL, RDMA,
RSZ, WROT, Some data routing between these blocks are fixed but
some are changeable. For application, we group them into display path
and mdp path. Clock gating register of these blocks are in the range of
0x1400 ~ 0x14000fff. The routing control register of these blocks
are also in the range of 0x1400 ~ 0x14000fff. So the control
function belong to mmsys partition but not belong to specific function
block would in the register range of 0x1400 ~ 0x14000fff. I think
there could be two definition of mmsys device. One is that mmsys device
is the whole mmsys partiotion, so OVL, RDMA, ... would be sub device of
it. Another is that mmsys just control register of 0x1400 ~
0x14000fff, so it's part of mmsys partition like OVL, RDMA, .
Currently we define mmsys as the latter one. I've no idea how to map
mmsys into current Linux hardware category, but I think it is not just a
display device.
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/mediatek/mt8173.dtsi?h=v5.6-rc1
Regards,
CK
> Thanks,
> Enric
>
>
> > I'm not sure if I understand you correctly. Are you proposing to keep the
> > binding description in arm/mediatek?
> >
> > Regards,
> > Matthias
> >
> >>
> >> [1] https://patchwork.kernel.org/patch/11140747/
> >>
> >> Regards,
> >> CK
> >>
> >>> Signed-off-by: Matthias Brugger
> >>>
> >>> ---
> >>>
> >>> Changes in v7:
> >>> - move the binding description
> >>>
> >>> Changes in v6: None
> >>> Changes in v5: None
> >>> Changes in v4: None
> >>> Changes in v3: None
> >>> Changes in v2: None
> >>>
> >>> .../bindings/{arm => display}/mediatek/mediatek,mmsys.txt | 0
> >>> 1 file changed, 0 insertions(+), 0 deletions(-)
> >>> rename Documentation/devicetree/bindings/{arm =>
> >>> display}/mediatek/mediatek,mmsys.txt (100%)
> >>>
> >>> diff --git
> >>> a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt
> >>> b/Documentation/devicetree/bindings/display/mediatek/mediatek,mmsys.txt
> >>> similarity index 100%
> >>> rename from
> >>> Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt
> >>> rename to
> >>> Documentation/devicetree/bindings/display/mediatek/mediatek,mmsys.txt
> >>
> >> ___
> >> linux-arm-kernel mailing list
> >> linux-arm-ker...@lists.infradead.org
> >> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> >>
>
> ___
> Linux-mediatek mailing list
> linux-media...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.9 039/141] drm/gma500: remove set but not used variable 'error'
From: zhengbin
[ Upstream commit a5eb29a9d2fc03d07af7d02f6c2e7ae1e6d985f9 ]
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/gma500/psb_irq.c: In function psb_sgx_interrupt:
drivers/gpu/drm/gma500/psb_irq.c:210:6: warning: variable error set but not
used [-Wunused-but-set-variable]
It is introduced by commit 64a4aff283ac ("drm/gma500:
Add support for SGX interrupts"), but never used, so remove it.
Reported-by: Hulk Robot
Signed-off-by: zhengbin
Signed-off-by: Daniel Vetter
Link:
https://patchwork.freedesktop.org/patch/msgid/1573828027-122323-3-git-send-email-zhengbi...@huawei.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/gma500/psb_irq.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/gma500/psb_irq.c b/drivers/gpu/drm/gma500/psb_irq.c
index 78eb109028091..f75f199c84311 100644
--- a/drivers/gpu/drm/gma500/psb_irq.c
+++ b/drivers/gpu/drm/gma500/psb_irq.c
@@ -207,7 +207,6 @@ static void psb_sgx_interrupt(struct drm_device *dev, u32
stat_1, u32 stat_2)
{
struct drm_psb_private *dev_priv = dev->dev_private;
u32 val, addr;
- int error = false;
if (stat_1 & _PSB_CE_TWOD_COMPLETE)
val = PSB_RSGX32(PSB_CR_2D_BLIT_STATUS);
@@ -242,7 +241,6 @@ static void psb_sgx_interrupt(struct drm_device *dev, u32
stat_1, u32 stat_2)
DRM_ERROR("\tMMU failing address is 0x%08x.\n",
(unsigned int)addr);
- error = true;
}
}
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.9 032/141] drm/amdgpu: remove 4 set but not used variable in amdgpu_atombios_get_connector_info_from_object_table
From: yu kuai
[ Upstream commit bae028e3e521e8cb8caf2cc16a455ce4c55f2332 ]
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c: In function
'amdgpu_atombios_get_connector_info_from_object_table':
drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:376:26: warning: variable
'grph_obj_num' set but not used [-Wunused-but-set-variable]
drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:376:13: warning: variable
'grph_obj_id' set but not used [-Wunused-but-set-variable]
drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:341:37: warning: variable
'con_obj_type' set but not used [-Wunused-but-set-variable]
drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:341:24: warning: variable
'con_obj_num' set but not used [-Wunused-but-set-variable]
They are never used, so can be removed.
Fixes: d38ceaf99ed0 ("drm/amdgpu: add core driver (v4)")
Signed-off-by: yu kuai
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c | 19 ++-
1 file changed, 2 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c
index 26afdffab5a06..ac8885562919d 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c
@@ -336,17 +336,9 @@ bool
amdgpu_atombios_get_connector_info_from_object_table(struct amdgpu_device *
path_size += le16_to_cpu(path->usSize);
if (device_support & le16_to_cpu(path->usDeviceTag)) {
- uint8_t con_obj_id, con_obj_num, con_obj_type;
-
- con_obj_id =
+ uint8_t con_obj_id =
(le16_to_cpu(path->usConnObjectId) & OBJECT_ID_MASK)
>> OBJECT_ID_SHIFT;
- con_obj_num =
- (le16_to_cpu(path->usConnObjectId) & ENUM_ID_MASK)
- >> ENUM_ID_SHIFT;
- con_obj_type =
- (le16_to_cpu(path->usConnObjectId) &
-OBJECT_TYPE_MASK) >> OBJECT_TYPE_SHIFT;
/* Skip TV/CV support */
if ((le16_to_cpu(path->usDeviceTag) ==
@@ -371,14 +363,7 @@ bool
amdgpu_atombios_get_connector_info_from_object_table(struct amdgpu_device *
router.ddc_valid = false;
router.cd_valid = false;
for (j = 0; j < ((le16_to_cpu(path->usSize) - 8) / 2);
j++) {
- uint8_t grph_obj_id, grph_obj_num,
grph_obj_type;
-
- grph_obj_id =
- (le16_to_cpu(path->usGraphicObjIds[j]) &
-OBJECT_ID_MASK) >> OBJECT_ID_SHIFT;
- grph_obj_num =
- (le16_to_cpu(path->usGraphicObjIds[j]) &
-ENUM_ID_MASK) >> ENUM_ID_SHIFT;
+ uint8_t grph_obj_type=
grph_obj_type =
(le16_to_cpu(path->usGraphicObjIds[j]) &
OBJECT_TYPE_MASK) >> OBJECT_TYPE_SHIFT;
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.9 040/141] drm/gma500: remove set but not used variable 'is_hdmi', 'is_crt'
From: zhengbin
[ Upstream commit 834c43a97f341d319aa7b74099bbce2c4e75bc72 ]
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/gma500/cdv_intel_display.c: In function cdv_intel_crtc_mode_set:
drivers/gpu/drm/gma500/cdv_intel_display.c:594:7: warning: variable is_hdmi set
but not used [-Wunused-but-set-variable]
drivers/gpu/drm/gma500/cdv_intel_display.c: In function cdv_intel_crtc_mode_set:
drivers/gpu/drm/gma500/cdv_intel_display.c:593:7: warning: variable is_crt set
but not used [-Wunused-but-set-variable]
They are not used since commit acd7ef927e06 ("gma500:
Update the Cedarview clock handling")
Reported-by: Hulk Robot
Signed-off-by: zhengbin
Signed-off-by: Daniel Vetter
Link:
https://patchwork.freedesktop.org/patch/msgid/1573828027-122323-4-git-send-email-zhengbi...@huawei.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/gma500/cdv_intel_display.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/gma500/cdv_intel_display.c
b/drivers/gpu/drm/gma500/cdv_intel_display.c
index 17db4b4749d5a..9854fdd7c51cf 100644
--- a/drivers/gpu/drm/gma500/cdv_intel_display.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_display.c
@@ -590,8 +590,8 @@ static int cdv_intel_crtc_mode_set(struct drm_crtc *crtc,
struct gma_clock_t clock;
u32 dpll = 0, dspcntr, pipeconf;
bool ok;
- bool is_crt = false, is_lvds = false, is_tv = false;
- bool is_hdmi = false, is_dp = false;
+ bool is_lvds = false, is_tv = false;
+ bool is_dp = false;
struct drm_mode_config *mode_config = >mode_config;
struct drm_connector *connector;
const struct gma_limit_t *limit;
@@ -615,10 +615,7 @@ static int cdv_intel_crtc_mode_set(struct drm_crtc *crtc,
is_tv = true;
break;
case INTEL_OUTPUT_ANALOG:
- is_crt = true;
- break;
case INTEL_OUTPUT_HDMI:
- is_hdmi = true;
break;
case INTEL_OUTPUT_DISPLAYPORT:
is_dp = true;
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.9 033/141] drm/amdgpu: remove set but not used variable 'dig_connector'
From: yu kuai
[ Upstream commit 5bea7fedb7fe4d5e6d3ba9f385dd3619fb004ce7 ]
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/amd/amdgpu/atombios_dp.c: In function
‘amdgpu_atombios_dp_get_panel_mode’:
drivers/gpu/drm/amd/amdgpu/atombios_dp.c:364:36: warning: variable
‘dig_connector’ set but not used [-Wunused-but-set-variable]
It is never used, so can be removed.
Fixes: d38ceaf99ed0 ("drm/amdgpu: add core driver (v4)")
Signed-off-by: yu kuai
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdgpu/atombios_dp.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
b/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
index f81068ba4cc67..d712dee892545 100644
--- a/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
+++ b/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
@@ -361,7 +361,6 @@ int amdgpu_atombios_dp_get_panel_mode(struct drm_encoder
*encoder,
struct drm_connector *connector)
{
struct amdgpu_connector *amdgpu_connector =
to_amdgpu_connector(connector);
- struct amdgpu_connector_atom_dig *dig_connector;
int panel_mode = DP_PANEL_MODE_EXTERNAL_DP_MODE;
u16 dp_bridge =
amdgpu_connector_encoder_get_dp_bridge_encoder_id(connector);
u8 tmp;
@@ -369,8 +368,6 @@ int amdgpu_atombios_dp_get_panel_mode(struct drm_encoder
*encoder,
if (!amdgpu_connector->con_priv)
return panel_mode;
- dig_connector = amdgpu_connector->con_priv;
-
if (dp_bridge != ENCODER_OBJECT_ID_NONE) {
/* DP bridge chips */
if (drm_dp_dpcd_readb(_connector->ddc_bus->aux,
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.9 038/141] drm/gma500: remove set but not used variable 'htotal'
From: zhengbin
[ Upstream commit dfa703b6f91818fa9f652c00e3589c104c518930 ]
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/gma500/oaktrail_hdmi.c: In function htotal_calculate:
drivers/gpu/drm/gma500/oaktrail_hdmi.c:160:6: warning: variable htotal set but
not used [-Wunused-but-set-variable]
It is introduced by commit 39ec748f7174 ("gma600: Enable HDMI support"),
but never used, so remove it.
Reported-by: Hulk Robot
Signed-off-by: zhengbin
Signed-off-by: Daniel Vetter
Link:
https://patchwork.freedesktop.org/patch/msgid/1573828027-122323-2-git-send-email-zhengbi...@huawei.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/gma500/oaktrail_hdmi.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/gma500/oaktrail_hdmi.c
b/drivers/gpu/drm/gma500/oaktrail_hdmi.c
index 8b2eb32ee988b..6b403c3586fa0 100644
--- a/drivers/gpu/drm/gma500/oaktrail_hdmi.c
+++ b/drivers/gpu/drm/gma500/oaktrail_hdmi.c
@@ -157,9 +157,7 @@ static void oaktrail_hdmi_audio_disable(struct drm_device
*dev)
static unsigned int htotal_calculate(struct drm_display_mode *mode)
{
- u32 htotal, new_crtc_htotal;
-
- htotal = (mode->crtc_hdisplay - 1) | ((mode->crtc_htotal - 1) << 16);
+ u32 new_crtc_htotal;
/*
* 1024 x 768 new_crtc_htotal = 0x1024;
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.9 037/141] drm/amdgpu: remove set but not used variable 'amdgpu_connector'
From: yu kuai
[ Upstream commit 4f2922d12d6c63d0f4aa4e859ad95aee6d0d4ea0 ]
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c: In function
‘amdgpu_display_crtc_scaling_mode_fixup’:
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c:693:27: warning: variable
‘amdgpu_connector’ set but not used [-Wunused-but-set-variable]
Fixes: d38ceaf99ed0 ("drm/amdgpu: add core driver (v4)")
Signed-off-by: yu kuai
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
index 15a2d8f3725d5..f29f025202d03 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
@@ -666,7 +666,6 @@ bool amdgpu_crtc_scaling_mode_fixup(struct drm_crtc *crtc,
struct amdgpu_crtc *amdgpu_crtc = to_amdgpu_crtc(crtc);
struct amdgpu_encoder *amdgpu_encoder;
struct drm_connector *connector;
- struct amdgpu_connector *amdgpu_connector;
u32 src_v = 1, dst_v = 1;
u32 src_h = 1, dst_h = 1;
@@ -678,7 +677,6 @@ bool amdgpu_crtc_scaling_mode_fixup(struct drm_crtc *crtc,
continue;
amdgpu_encoder = to_amdgpu_encoder(encoder);
connector = amdgpu_get_connector_for_encoder(encoder);
- amdgpu_connector = to_amdgpu_connector(connector);
/* set scaling */
if (amdgpu_encoder->rmx_type == RMX_OFF)
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.9 042/141] drm/radeon: remove set but not used variable 'size', 'relocs_chunk'
From: zhengbin
[ Upstream commit e9f782dd22c0e17874b8b8e12aafcd3a06810dd0 ]
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/radeon/r600_cs.c: In function r600_cs_track_validate_cb:
drivers/gpu/drm/radeon/r600_cs.c:353:22: warning: variable size set but not
used [-Wunused-but-set-variable]
drivers/gpu/drm/radeon/r600_cs.c: In function r600_cs_track_validate_db:
drivers/gpu/drm/radeon/r600_cs.c:520:27: warning: variable size set but not
used [-Wunused-but-set-variable]
drivers/gpu/drm/radeon/r600_cs.c: In function r600_dma_cs_next_reloc:
drivers/gpu/drm/radeon/r600_cs.c:2345:26: warning: variable relocs_chunk set
but not used [-Wunused-but-set-variable]
The first 'size' is not used since commit f30df2fad0c9 ("drm/radeon/r600:
fix tiling issues in CS checker.")
The second 'size' is introduced by commit 88f50c80748b ("drm/radeon/kms:
add htile support to the cs checker v3"), but never used, so remove it.
'relocs_chunk' is not used since commit 9305ede6afe2 ("radeon/kms:
fix dma relocation checking")
Reported-by: Hulk Robot
Signed-off-by: zhengbin
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/radeon/r600_cs.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r600_cs.c b/drivers/gpu/drm/radeon/r600_cs.c
index b69c8de35bd31..4e60c865f21c5 100644
--- a/drivers/gpu/drm/radeon/r600_cs.c
+++ b/drivers/gpu/drm/radeon/r600_cs.c
@@ -349,7 +349,7 @@ static void r600_cs_track_init(struct r600_cs_track *track)
static int r600_cs_track_validate_cb(struct radeon_cs_parser *p, int i)
{
struct r600_cs_track *track = p->track;
- u32 slice_tile_max, size, tmp;
+ u32 slice_tile_max, tmp;
u32 height, height_align, pitch, pitch_align, depth_align;
u64 base_offset, base_align;
struct array_mode_checker array_check;
@@ -359,7 +359,6 @@ static int r600_cs_track_validate_cb(struct
radeon_cs_parser *p, int i)
/* When resolve is used, the second colorbuffer has always 1 sample. */
unsigned nsamples = track->is_resolve && i == 1 ? 1 : track->nsamples;
- size = radeon_bo_size(track->cb_color_bo[i]) -
track->cb_color_bo_offset[i];
format = G_0280A0_FORMAT(track->cb_color_info[i]);
if (!r600_fmt_is_valid_color(format)) {
dev_warn(p->dev, "%s:%d cb invalid format %d for %d (0x%08X)\n",
@@ -516,7 +515,7 @@ static int r600_cs_track_validate_cb(struct
radeon_cs_parser *p, int i)
static int r600_cs_track_validate_db(struct radeon_cs_parser *p)
{
struct r600_cs_track *track = p->track;
- u32 nviews, bpe, ntiles, size, slice_tile_max, tmp;
+ u32 nviews, bpe, ntiles, slice_tile_max, tmp;
u32 height_align, pitch_align, depth_align;
u32 pitch = 8192;
u32 height = 8192;
@@ -563,7 +562,6 @@ static int r600_cs_track_validate_db(struct
radeon_cs_parser *p)
}
ib[track->db_depth_size_idx] = S_028000_SLICE_TILE_MAX(tmp - 1)
| (track->db_depth_size & 0x3FF);
} else {
- size = radeon_bo_size(track->db_bo);
/* pitch in pixels */
pitch = (G_028000_PITCH_TILE_MAX(track->db_depth_size) + 1) * 8;
slice_tile_max = G_028000_SLICE_TILE_MAX(track->db_depth_size)
+ 1;
@@ -2342,7 +2340,6 @@ int r600_cs_parse(struct radeon_cs_parser *p)
int r600_dma_cs_next_reloc(struct radeon_cs_parser *p,
struct radeon_bo_list **cs_reloc)
{
- struct radeon_cs_chunk *relocs_chunk;
unsigned idx;
*cs_reloc = NULL;
@@ -2350,7 +2347,6 @@ int r600_dma_cs_next_reloc(struct radeon_cs_parser *p,
DRM_ERROR("No relocation chunk !\n");
return -EINVAL;
}
- relocs_chunk = p->chunk_relocs;
idx = p->dma_reloc_idx;
if (idx >= p->nrelocs) {
DRM_ERROR("Relocs at %d after relocations chunk end %d !\n",
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.9 001/141] drm/gma500: Fixup fbdev stolen size usage evaluation
From: Paul Kocialkowski
[ Upstream commit fd1a5e521c3c083bb43ea731aae0f8b95f12b9bd ]
psbfb_probe performs an evaluation of the required size from the stolen
GTT memory, but gets it wrong in two distinct ways:
- The resulting size must be page-size-aligned;
- The size to allocate is derived from the surface dimensions, not the fb
dimensions.
When two connectors are connected with different modes, the smallest will
be stored in the fb dimensions, but the size that needs to be allocated must
match the largest (surface) dimensions. This is what is used in the actual
allocation code.
Fix this by correcting the evaluation to conform to the two points above.
It allows correctly switching to 16bpp when one connector is e.g. 1920x1080
and the other is 1024x768.
Signed-off-by: Paul Kocialkowski
Signed-off-by: Patrik Jakobsson
Link:
https://patchwork.freedesktop.org/patch/msgid/20191107153048.843881-1-paul.kocialkow...@bootlin.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/gma500/framebuffer.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/gma500/framebuffer.c
b/drivers/gpu/drm/gma500/framebuffer.c
index 3a44e705db538..d224fc12b7571 100644
--- a/drivers/gpu/drm/gma500/framebuffer.c
+++ b/drivers/gpu/drm/gma500/framebuffer.c
@@ -516,6 +516,7 @@ static int psbfb_probe(struct drm_fb_helper *helper,
container_of(helper, struct psb_fbdev, psb_fb_helper);
struct drm_device *dev = psb_fbdev->psb_fb_helper.dev;
struct drm_psb_private *dev_priv = dev->dev_private;
+ unsigned int fb_size;
int bytespp;
bytespp = sizes->surface_bpp / 8;
@@ -525,8 +526,11 @@ static int psbfb_probe(struct drm_fb_helper *helper,
/* If the mode will not fit in 32bit then switch to 16bit to get
a console on full resolution. The X mode setting server will
allocate its own 32bit GEM framebuffer */
- if (ALIGN(sizes->fb_width * bytespp, 64) * sizes->fb_height >
- dev_priv->vram_stolen_size) {
+ fb_size = ALIGN(sizes->surface_width * bytespp, 64) *
+ sizes->surface_height;
+ fb_size = ALIGN(fb_size, PAGE_SIZE);
+
+ if (fb_size > dev_priv->vram_stolen_size) {
sizes->surface_bpp = 16;
sizes->surface_depth = 16;
}
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.9 009/141] pxa168fb: Fix the function used to release some memory in an error handling path
From: Christophe JAILLET
[ Upstream commit 3c911fe799d1c338d94b78e7182ad452c37af897 ]
In the probe function, some resources are allocated using 'dma_alloc_wc()',
they should be released with 'dma_free_wc()', not 'dma_free_coherent()'.
We already use 'dma_free_wc()' in the remove function, but not in the
error handling path of the probe function.
Also, remove a useless 'PAGE_ALIGN()'. 'info->fix.smem_len' is already
PAGE_ALIGNed.
Fixes: 638772c7553f ("fb: add support of LCD display controller on pxa168/910
(base layer)")
Signed-off-by: Christophe JAILLET
Reviewed-by: Lubomir Rintel
CC: YueHaibing
Signed-off-by: Bartlomiej Zolnierkiewicz
Link:
https://patchwork.freedesktop.org/patch/msgid/20190831100024.3248-1-christophe.jail...@wanadoo.fr
Signed-off-by: Sasha Levin
---
drivers/video/fbdev/pxa168fb.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/video/fbdev/pxa168fb.c b/drivers/video/fbdev/pxa168fb.c
index d059d04c63acd..20195d3dbf088 100644
--- a/drivers/video/fbdev/pxa168fb.c
+++ b/drivers/video/fbdev/pxa168fb.c
@@ -769,8 +769,8 @@ static int pxa168fb_probe(struct platform_device *pdev)
failed_free_clk:
clk_disable_unprepare(fbi->clk);
failed_free_fbmem:
- dma_free_coherent(fbi->dev, info->fix.smem_len,
- info->screen_base, fbi->fb_start_dma);
+ dma_free_wc(fbi->dev, info->fix.smem_len,
+ info->screen_base, fbi->fb_start_dma);
failed_free_info:
kfree(info);
@@ -804,7 +804,7 @@ static int pxa168fb_remove(struct platform_device *pdev)
irq = platform_get_irq(pdev, 0);
- dma_free_wc(fbi->dev, PAGE_ALIGN(info->fix.smem_len),
+ dma_free_wc(fbi->dev, info->fix.smem_len,
info->screen_base, info->fix.smem_start);
clk_disable_unprepare(fbi->clk);
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.14 170/186] drm/nouveau/disp/nv50-: prevent oops when no channel method map provided
From: Ben Skeggs
[ Upstream commit 0e6176c6d286316e9431b4f695940cfac4ffe6c2 ]
The implementations for most channel types contains a map of methods to
priv registers in order to provide debugging info when a disp exception
has been raised.
This info is missing from the implementation of PIO channels as they're
rather simplistic already, however, if an exception is raised by one of
them, we'd end up triggering a NULL-pointer deref. Not ideal...
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=206299
Signed-off-by: Ben Skeggs
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/nouveau/nvkm/engine/disp/channv50.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/disp/channv50.c
b/drivers/gpu/drm/nouveau/nvkm/engine/disp/channv50.c
index 0c0310498afdb..cd9666583d4bd 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/disp/channv50.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/disp/channv50.c
@@ -73,6 +73,8 @@ nv50_disp_chan_mthd(struct nv50_disp_chan *chan, int debug)
if (debug > subdev->debug)
return;
+ if (!mthd)
+ return;
for (i = 0; (list = mthd->data[i].mthd) != NULL; i++) {
u32 base = chan->head * mthd->addr;
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.14 174/186] radeon: insert 10ms sleep in dce5_crtc_load_lut
From: Daniel Vetter
[ Upstream commit ec3d65082d7dabad6fa8f66a8ef166f2d522d6b2 ]
Per at least one tester this is enough magic to recover the regression
introduced for some people (but not all) in
commit b8e2b0199cc377617dc238f5106352c06dcd3fa2
Author: Peter Rosin
Date: Tue Jul 4 12:36:57 2017 +0200
drm/fb-helper: factor out pseudo-palette
which for radeon had the side-effect of refactoring out a seemingly
redudant writing of the color palette.
10ms in a fairly slow modeset path feels like an acceptable form of
duct-tape, so maybe worth a shot and see what sticks.
Cc: Alex Deucher
Cc: Michel Dänzer
References: https://bugzilla.kernel.org/show_bug.cgi?id=198123
Signed-off-by: Daniel Vetter
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/radeon/radeon_display.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/radeon/radeon_display.c
b/drivers/gpu/drm/radeon/radeon_display.c
index 4ed80bf5d3f0d..a21647dce3bf5 100644
--- a/drivers/gpu/drm/radeon/radeon_display.c
+++ b/drivers/gpu/drm/radeon/radeon_display.c
@@ -119,6 +119,8 @@ static void dce5_crtc_load_lut(struct drm_crtc *crtc)
DRM_DEBUG_KMS("%d\n", radeon_crtc->crtc_id);
+ msleep(10);
+
WREG32(NI_INPUT_CSC_CONTROL + radeon_crtc->crtc_offset,
(NI_INPUT_CSC_GRPH_MODE(NI_INPUT_CSC_BYPASS) |
NI_INPUT_CSC_OVL_MODE(NI_INPUT_CSC_BYPASS)));
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.14 128/186] drm/vmwgfx: prevent memory leak in vmw_cmdbuf_res_add
From: Navid Emamdoost
[ Upstream commit 40efb09a7f53125719e49864da008495e39aaa1e ]
In vmw_cmdbuf_res_add if drm_ht_insert_item fails the allocated memory
for cres should be released.
Fixes: 18e4a4669c50 ("drm/vmwgfx: Fix compat shader namespace")
Signed-off-by: Navid Emamdoost
Reviewed-by: Thomas Hellstrom
Signed-off-by: Thomas Hellstrom
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf_res.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf_res.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf_res.c
index 36c7b6c839c0d..738ad2fc79a25 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf_res.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf_res.c
@@ -210,8 +210,10 @@ int vmw_cmdbuf_res_add(struct vmw_cmdbuf_res_manager *man,
cres->hash.key = user_key | (res_type << 24);
ret = drm_ht_insert_item(>resources, >hash);
- if (unlikely(ret != 0))
+ if (unlikely(ret != 0)) {
+ kfree(cres);
goto out_invalid_key;
+ }
cres->state = VMW_CMDBUF_RES_ADD;
cres->res = vmw_resource_reference(res);
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.14 127/186] drm/nouveau: Fix copy-paste error in nouveau_fence_wait_uevent_handler
From: YueHaibing
[ Upstream commit 1eb013473bff5f95b6fe1ca4dd7deda47257b9c2 ]
Like other cases, it should use rcu protected 'chan' rather
than 'fence->channel' in nouveau_fence_wait_uevent_handler.
Fixes: 0ec5f02f0e2c ("drm/nouveau: prevent stale fence->channel pointers, and
protect with rcu")
Signed-off-by: YueHaibing
Signed-off-by: Ben Skeggs
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/nouveau/nouveau_fence.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c
b/drivers/gpu/drm/nouveau/nouveau_fence.c
index 99e14e3e0fe4d..72532539369fb 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fence.c
+++ b/drivers/gpu/drm/nouveau/nouveau_fence.c
@@ -158,7 +158,7 @@ nouveau_fence_wait_uevent_handler(struct nvif_notify
*notify)
fence = list_entry(fctx->pending.next, typeof(*fence), head);
chan = rcu_dereference_protected(fence->channel,
lockdep_is_held(>lock));
- if (nouveau_fence_update(fence->channel, fctx))
+ if (nouveau_fence_update(chan, fctx))
ret = NVIF_NOTIFY_DROP;
}
spin_unlock_irqrestore(>lock, flags);
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.14 125/186] drm/nouveau/secboot/gm20b: initialize pointer in gm20b_secboot_new()
From: Dan Carpenter
[ Upstream commit 3613a9bea95a1470dd42e4ed1cc7d86ebe0a2dc0 ]
We accidentally set "psb" which is a no-op instead of "*psb" so it
generates a static checker warning. We should probably set it before
the first error return so that it's always initialized.
Fixes: 923f1bd27bf1 ("drm/nouveau/secboot/gm20b: add secure boot support")
Signed-off-by: Dan Carpenter
Signed-off-by: Ben Skeggs
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/nouveau/nvkm/subdev/secboot/gm20b.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/secboot/gm20b.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/secboot/gm20b.c
index 30491d132d59c..fbd10a67c6c6a 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/secboot/gm20b.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/secboot/gm20b.c
@@ -108,6 +108,7 @@ gm20b_secboot_new(struct nvkm_device *device, int index,
struct gm200_secboot *gsb;
struct nvkm_acr *acr;
+ *psb = NULL;
acr = acr_r352_new(BIT(NVKM_SECBOOT_FALCON_FECS) |
BIT(NVKM_SECBOOT_FALCON_PMU));
if (IS_ERR(acr))
@@ -116,10 +117,8 @@ gm20b_secboot_new(struct nvkm_device *device, int index,
acr->optional_falcons = BIT(NVKM_SECBOOT_FALCON_PMU);
gsb = kzalloc(sizeof(*gsb), GFP_KERNEL);
- if (!gsb) {
- psb = NULL;
+ if (!gsb)
return -ENOMEM;
- }
*psb = >base;
ret = nvkm_secboot_ctor(_secboot, acr, device, index, >base);
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
