Re: [PATCH v1 1/5] dt-bindings: arm: mediatek: mmsys: add mt8195 SoC binding
On Fri, 2021-07-23 at 13:13 +0200, Enric Balletbo Serra wrote:
> Hi Jason,
>
> Thank you for your patch.
>
> Missatge de jason-jh.lin del dia dj., 22
> de jul. 2021 a les 11:26:
> >
> > There are 2 display hardware path in mt8195, namely vdosys0 and
> > vdosys1, so add their definition in mtk-mmsys documentation.
> >
>
> Just having 2 display hardware paths is not a reason to have two
> compatibles, isn't the IP block the same? Why do you need to
> introduce
> the two compatibles?
>
> Thanks,
> Enric
>
Hi Enric,
Thanks for reviewing my patch.
The reason for using two compatibles is that vdosys0 and vdosys1 are
different IP blocks.
Because mmsys provides clock control, other display function blocks may
use them as clock provider.
E.g.
1. mmsys with compatible="mediatek,mt8195-vdosys0"
[v4,1/6] arm64: dts: mt8195: add display node for vdosys0
https://patchwork.kernel.org/project/linux-mediatek/patch/20210723090233.24007-2-jason-jh@mediatek.com/
ovl0: disp_ovl@1c00 {
...
clocks = <&vdosys0 CLK_VDO0_DISP_OVL0>;
...
};
2. mmsys with compatible="mediatek,mt8195-vdosys1"
[v2,06/14] arm64: dts: mt8195: add display node for vdosys1
https://patchwork.kernel.org/project/linux-mediatek/patch/20210722094551.15255-7-nancy@mediatek.com/
vdo1_rdma0: vdo1_rdma@1c104000 {
...
clocks = <&vdosys1 CLK_VDO1_MDP_RDMA0>;
...
};
Regards,
Jason-JH.Lin
> > Signed-off-by: jason-jh.lin
> > ---
> > this patch is base on [1][2]
> >
> > [1] dt-bindings: arm: mediatek: mmsys: convert to YAML format
> > -
> > https://urldefense.com/v3/__https://patchwork.kernel.org/project/linux-mediatek/patch/20210519161847.3747352-1-fpar...@baylibre.com/__;!!CTRNKA9wMg0ARbw!ycgPEK4yBDojiiZJC2E9mGwvxJbaLqhyUxzJIq0ckEP-JVteBcjFdc6ixkNbmknH8f2P$
> >
> > [2] dt-bindings: arm: mediatek: mmsys: add MT8365 SoC binding
> > -
> > https://urldefense.com/v3/__https://patchwork.kernel.org/project/linux-mediatek/patch/20210519161847.3747352-2-fpar...@baylibre.com/__;!!CTRNKA9wMg0ARbw!ycgPEK4yBDojiiZJC2E9mGwvxJbaLqhyUxzJIq0ckEP-JVteBcjFdc6ixkNbmju2GBrD$
> >
> > ---
> > .../devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml|
> > 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git
> > a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yam
> > l
> > b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yam
> > l
> > index 2d4ff0ce387b..0789a9614f12 100644
> > ---
> > a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yam
> > l
> > +++
> > b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yam
> > l
> > @@ -30,6 +30,8 @@ properties:
> >- mediatek,mt8173-mmsys
> >- mediatek,mt8183-mmsys
> >- mediatek,mt8365-mmsys
> > + - mediatek,mt8195-vdosys0
> > + - mediatek,mt8195-vdosys1
> >- const: syscon
> >- items:
> >- const: mediatek,mt7623-mmsys
> > --
> > 2.18.0
> >
--
Re: [PATCH v3 1/2] dt-bindings: panel: Add Samsung S6E3FA2 panel
Hi Iskren, thanks for your patch! On Mon, Feb 1, 2021 at 5:56 PM Iskren Chernev wrote: > +required: > + - compatible > + - reset-gpios > + - iovdd-supply > + - vddr-supply > + - port I do not think port should be required because the DSI framework allows panels to be put as children right inside the DSI controller node without any port linking the two. Other than that it looks good! Yours, Linus Walleij
Re: [PATCH v3 2/2] drm/panel: Add panel for Samsung Galaxy S5
Hi Iskren,
thanks for your patch!
On Mon, Feb 1, 2021 at 5:56 PM Iskren Chernev wrote:
> The Samsung Galaxy S5 uses the samsung s6e3fa2 AMOLED cmd LCD panel.
>
> This driver was generated with [1], with the addition of
> mipi_dsi_dcs_set_display_on at the end of the on method.
>
> [1] https://github.com/msm8916-mainline/linux-mdss-dsi-panel-driver-generator
>
> Signed-off-by: Iskren Chernev
(...)
> +config DRM_PANEL_SAMSUNG_S6E3FA2
> + tristate "Samsung S6E3FA2 DSI cmd mode panel"
Spell it out "command mode" no need to abbreviate.
> +struct samsung_s6e3fa2 {
> + struct drm_panel panel;
> + struct mipi_dsi_device *dsi;
> + struct regulator_bulk_data supplies[2];
> + struct gpio_desc *reset_gpio;
> + bool prepared;
Why do you need to keep track of prepared?
The framework already does that and that is why it keeps
different callbacks for prepare and enable.
> +#define dsi_generic_write_seq(dsi, seq...) do {
> \
> + static const u8 d[] = { seq }; \
> + int ret;\
> + ret = mipi_dsi_generic_write(dsi, d, ARRAY_SIZE(d));\
> + if (ret < 0)\
> + return ret; \
> + } while (0)
> +
> +#define dsi_dcs_write_seq(dsi, seq...) do {\
> + static const u8 d[] = { seq }; \
> + int ret;\
> + ret = mipi_dsi_dcs_write_buffer(dsi, d, ARRAY_SIZE(d)); \
> + if (ret < 0)\
> + return ret; \
> + } while (0)
Maybe this is something we should add to
include/drm/drm_mipi_dsi.h?
It looks very generic and helpful.
> +static void samsung_s6e3fa2_reset(struct samsung_s6e3fa2 *ctx)
> +{
> + gpiod_set_value_cansleep(ctx->reset_gpio, 0);
> + usleep_range(5000, 6000);
There is really no need to do this, the next statement asserts
reset. It looks like a copy/paste thing from a less informed
framework.
> + gpiod_set_value_cansleep(ctx->reset_gpio, 1);
> + usleep_range(5000, 6000);
> + gpiod_set_value_cansleep(ctx->reset_gpio, 0);
> + usleep_range(7000, 8000);
These two look good.
> +static int samsung_s6e3fa2_on(struct samsung_s6e3fa2 *ctx)
> +{
> + struct mipi_dsi_device *dsi = ctx->dsi;
> + struct device *dev = &dsi->dev;
> + int ret;
> +
> + dsi->mode_flags |= MIPI_DSI_MODE_LPM;
> +
> + dsi_generic_write_seq(dsi, 0xf0, 0x5a, 0x5a);
> + dsi_generic_write_seq(dsi, 0xfc, 0x5a, 0x5a);
These are very similar to other Samsung panels so you can definately
add this to your driver:
#define S6E3FA2_LEVEL_2_KEY 0xf0
> + dsi_generic_write_seq(dsi, 0xf0, 0xa5, 0xa5);
> + dsi_generic_write_seq(dsi, 0xfc, 0xa5, 0xa5);
Add a comment that this locks level 2 control again.
> +static int samsung_s6e3fa2_prepare(struct drm_panel *panel)
> +{
> + struct samsung_s6e3fa2 *ctx = to_samsung_s6e3fa2(panel);
> + struct device *dev = &ctx->dsi->dev;
> + int ret;
> +
> + if (ctx->prepared)
> + return 0;
Looks unnecessary. The framework should keep track of this.
> + dsi->lanes = 4;
> + dsi->format = MIPI_DSI_FMT_RGB888;
> + dsi->mode_flags = MIPI_DSI_MODE_VIDEO_BURST |
> + MIPI_DSI_CLOCK_NON_CONTINUOUS;
You are not setting dsi->hs_rate and dsi->lp_rate.
The panel definitely has these max timings so when you
don't set them the DSI host will just go with some defaults
(some of them don't even allow you to configure this).
For reusability it would be great if you know roughly what these
clocks are, sometimes board files in vendor trees give a hint.
Worst case drop a comment that HS and LP rates are unknown.
I also wonder if the panel can report an MTP ID?
If you add some code like this and call from prepare(), what
happens?
#define READ_ID1 0xda /* Read panel ID 1 */
#define READ_ID2 0xdb /* Read panel ID 2 */
#define READ_ID3 0xdc /* Read panel ID 3 */
static int s6e3fa2_read_id(struct samsung_s6e3fa2 *ctx)
{
struct mipi_dsi_device *dsi = ctx->dsi;
struct device *dev = &dsi->dev;
u8 id1, id2, id3;
int ret;
ret = mipi_dsi_dcs_read(dsi, READ_ID1, &id1, 1);
if (ret < 0) {
dev_err(dev, "could not read MTP ID1\n");
return ret;
}
ret = mipi_dsi_dcs_read(dsi, READ_ID2, &id2, 1);
if (ret < 0) {
dev_err(dev, "could not read MTP ID2\n");
return ret;
}
ret = mipi_dsi_dcs_read(dsi, READ_ID3, &id3, 1);
if (ret < 0) {
Re: [PATCH 2/2] drm/panel: Add Samsung S6E3FA2 DSI panel driver
On Sun, Jul 25, 2021 at 5:01 PM Sam Ravnborg wrote:
> This driver supports two different panels:
>
> S6E3FA2
> EA8064G
>
> They differ on a lot of the tables and requires different init.
> In other words there is only a little boiler plate code that is in
> common.
>
> I think it would be much cleaner with individual drivers for each panel.
Sometimes Samsung have different *physical* panels connected
to the same display controller, but I don't know what is the case
here. This looks like it could actually be two different display
controllers. (I don't like these opaque binary drops from Samsung,
datasheets would be nice...)
What I think is most intuitive is to have one driver per display controller.
If the two drivers are writing some very similar registers with very
similar values they are probably the same display controller.
If they are not then they are not...
If they are obviously the same display controller I think parameterizing
a display controller driver along the line of panel-novatek-nt35510.c
is the best. If different display controllers, we need different drivers.
> Which brings me to next topic - this is two different panels and the DT
> are supports to describe the HW - so the DT tree should have different
> entries depending on the actual panel. As it is now you try to hide the
> fact that one compatible describes two different panels.
(...)
> > + ret = s6e3fa2_dsi_dcs_read1(dsi, MCS_READ_ID1, &id1);
> > + if (ret < 0)
> > + return ret;
> > + ret = s6e3fa2_dsi_dcs_read1(dsi, MCS_READ_ID2, &id2);
> > + if (ret < 0)
> > + return ret;
> > + ret = s6e3fa2_dsi_dcs_read1(dsi, MCS_READ_ID3, &id3);
> > + if (ret < 0)
> > + return ret;
> > +
> > + lcd_id = id1 << 16 | id2 << 8 | id3;
> > +
> > + switch (lcd_id) {
> > + case LCD_ID_S6E3FA2:
> > + dev_info(&dsi->dev, "detected S6E3FA2 panel (ID: 0x%x)\n",
> > + lcd_id);
> > + ctx->subtype = PANEL_S6E3FA2;
> > + ctx->seq_data = &seqdata_s6e3fa2;
> > + break;
> > + case LCD_ID_EA8064G:
> > + dev_info(&dsi->dev, "detected EA8064G panel (ID: 0x%x)\n",
> > + lcd_id);
> > + ctx->subtype = PANEL_EA8064G;
> > + ctx->seq_data = &seqdata_ea8064g;
> > + break;
> > + default:
> > + dev_warn(&dsi->dev, "unsupported panel ID: 0x%x\n", lcd_id);
> > + ctx->subtype = PANEL_UNKNOWN;
This does look like two different panels, I'd like to know the MTP
IDs printed (also wrote in different mail). The MTP print I think
should be kept.
Yours,
Linus Walleij
[PATCH v2] drm: add logging for RMFB ioctl
We already have logging for ADDFB2. Add some logging for RMFB as
well.
This can be handy when trying to find out why a CRTC gets magically
disabled.
v2: make log message more explicit, add log messages to
drm_framebuffer_remove (Daniel)
Signed-off-by: Simon Ser
Cc: Daniel Vetter
---
drivers/gpu/drm/drm_framebuffer.c | 22 +-
1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_framebuffer.c
b/drivers/gpu/drm/drm_framebuffer.c
index 4d01464b6f95..d3d09aba9833 100644
--- a/drivers/gpu/drm/drm_framebuffer.c
+++ b/drivers/gpu/drm/drm_framebuffer.c
@@ -404,6 +404,9 @@ static void drm_mode_rmfb_work_fn(struct work_struct *w)
struct drm_framebuffer *fb =
list_first_entry(&arg->fbs, typeof(*fb), filp_head);
+ drm_dbg_kms(fb->dev,
+ "Removing [FB:%d] from all active usage due to RMFB
ioctl\n",
+ fb->base.id);
list_del_init(&fb->filp_head);
drm_framebuffer_remove(fb);
}
@@ -981,6 +984,10 @@ static int atomic_remove_fb(struct drm_framebuffer *fb)
if (plane->state->fb != fb)
continue;
+ drm_dbg_kms(dev,
+ "Disabling [PLANE:%d:%s] because [FB:%d] is
removed\n",
+ plane->base.id, plane->name, fb->base.id);
+
plane_state = drm_atomic_get_plane_state(state, plane);
if (IS_ERR(plane_state)) {
ret = PTR_ERR(plane_state);
@@ -990,6 +997,11 @@ static int atomic_remove_fb(struct drm_framebuffer *fb)
if (disable_crtcs && plane_state->crtc->primary == plane) {
struct drm_crtc_state *crtc_state;
+ drm_dbg_kms(dev,
+ "Disabling [CRTC:%d:%s] because [FB:%d] is
removed\n",
+ plane_state->crtc->base.id,
+ plane_state->crtc->name, fb->base.id);
+
crtc_state = drm_atomic_get_existing_crtc_state(state,
plane_state->crtc);
ret = drm_atomic_add_affected_connectors(state,
plane_state->crtc);
@@ -1052,6 +1064,10 @@ static void legacy_remove_fb(struct drm_framebuffer *fb)
/* remove from any CRTC */
drm_for_each_crtc(crtc, dev) {
if (crtc->primary->fb == fb) {
+ drm_dbg_kms(dev,
+ "Disabling [CRTC:%d:%s] because [FB:%d] is
removed\n",
+ crtc->base.id, crtc->name, fb->base.id);
+
/* should turn off the crtc */
if (drm_crtc_force_disable(crtc))
DRM_ERROR("failed to reset crtc %p when fb was
deleted\n", crtc);
@@ -1059,8 +1075,12 @@ static void legacy_remove_fb(struct drm_framebuffer *fb)
}
drm_for_each_plane(plane, dev) {
- if (plane->fb == fb)
+ if (plane->fb == fb) {
+ drm_dbg_kms(dev,
+ "Disabling [PLANE:%d:%s] because [FB:%d] is
removed\n",
+ plane->base.id, plane->name, fb->base.id);
drm_plane_force_disable(plane);
+ }
}
drm_modeset_unlock_all(dev);
}
--
2.32.0
[PATCH] drm: document DRM_IOCTL_MODE_RMFB
Since there's no struct to attach the docs to, document the IOCTL
definition.
Signed-off-by: Simon Ser
Cc: Daniel Vetter
Cc: Pekka Paalanen
Cc: Leandro Ribeiro
---
include/uapi/drm/drm.h | 10 ++
1 file changed, 10 insertions(+)
diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index e1f49dd241f7..283d61d5a243 100644
--- a/include/uapi/drm/drm.h
+++ b/include/uapi/drm/drm.h
@@ -1050,6 +1050,16 @@ extern "C" {
#define DRM_IOCTL_MODE_GETPROPBLOB DRM_IOWR(0xAC, struct drm_mode_get_blob)
#define DRM_IOCTL_MODE_GETFB DRM_IOWR(0xAD, struct drm_mode_fb_cmd)
#define DRM_IOCTL_MODE_ADDFB DRM_IOWR(0xAE, struct drm_mode_fb_cmd)
+/**
+ * DRM_IOCTL_MODE_RMFB - Remove a framebuffer.
+ *
+ * This removes a framebuffer previously added via ADDFB/ADDFB2. The IOCTL
+ * argument is a framebuffer object ID.
+ *
+ * Warning: removing a framebuffer currently in-use on an enabled plane will
+ * disable that plane. If the plane is primary, the CRTC may also be disabled
+ * (depending on driver capabilities).
+ */
#define DRM_IOCTL_MODE_RMFBDRM_IOWR(0xAF, unsigned int)
#define DRM_IOCTL_MODE_PAGE_FLIP DRM_IOWR(0xB0, struct
drm_mode_crtc_page_flip)
#define DRM_IOCTL_MODE_DIRTYFB DRM_IOWR(0xB1, struct
drm_mode_fb_dirty_cmd)
--
2.32.0
Re: [PATCH 1/2] dt-bindings: panel: Add Samsung S6E3FA2 panel
On Sun, Jul 25, 2021 at 4:04 PM Alexey Minnekhanov wrote: > The Samsung S6E3FA2 AMOLED cmd LCD panel is used on Samsung Galaxy > S5 (klte) phone. > > Signed-off-by: Alexey Minnekhanov Grr gmail put this in my spam folder, sorry for confused mails. With Sam's comments addressed: Reviewed-by: Linus Walleij Yours, Linus Walleij
Re: [Intel-gfx] [PATCH] drm/i915/userptr: Probe existence of backing struct pages upon creation
On Fri, 23 Jul 2021 at 18:49, Jason Ekstrand wrote:
>
> Are there IGTs for this anywhere?
https://patchwork.freedesktop.org/series/92580/
>
> On Fri, Jul 23, 2021 at 12:47 PM Jason Ekstrand wrote:
> >
> > https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12044
> >
> > On Fri, Jul 23, 2021 at 6:35 AM Matthew Auld wrote:
> > >
> > > From: Chris Wilson
> > >
> > > Jason Ekstrand requested a more efficient method than userptr+set-domain
> > > to determine if the userptr object was backed by a complete set of pages
> > > upon creation. To be more efficient than simply populating the userptr
> > > using get_user_pages() (as done by the call to set-domain or execbuf),
> > > we can walk the tree of vm_area_struct and check for gaps or vma not
> > > backed by struct page (VM_PFNMAP). The question is how to handle
> > > VM_MIXEDMAP which may be either struct page or pfn backed...
> > >
> > > With discrete we are going to drop support for set_domain(), so offering
> > > a way to probe the pages, without having to resort to dummy batches has
> > > been requested.
> > >
> > > v2:
> > > - add new query param for the PROBE flag, so userspace can easily
> > > check if the kernel supports it(Jason).
> > > - use mmap_read_{lock, unlock}.
> > > - add some kernel-doc.
> > > v3:
> > > - In the docs also mention that PROBE doesn't guarantee that the pages
> > > will remain valid by the time they are actually used(Tvrtko).
> > > - Add a small comment for the hole finding logic(Jason).
> > > - Move the param next to all the other params which just return true.
> > >
> > > Testcase: igt/gem_userptr_blits/probe
> > > Signed-off-by: Chris Wilson
> > > Signed-off-by: Matthew Auld
> > > Cc: Thomas Hellström
> > > Cc: Maarten Lankhorst
> > > Cc: Tvrtko Ursulin
> > > Cc: Jordan Justen
> > > Cc: Kenneth Graunke
> > > Cc: Jason Ekstrand
> > > Cc: Daniel Vetter
> > > Cc: Ramalingam C
> > > Reviewed-by: Tvrtko Ursulin
> > > Acked-by: Kenneth Graunke
> > > Reviewed-by: Jason Ekstrand
> > > ---
> > > drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 41 -
> > > drivers/gpu/drm/i915/i915_getparam.c| 1 +
> > > include/uapi/drm/i915_drm.h | 20 ++
> > > 3 files changed, 61 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
> > > b/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
> > > index 56edfeff8c02..468a7a617fbf 100644
> > > --- a/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
> > > +++ b/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
> > > @@ -422,6 +422,34 @@ static const struct drm_i915_gem_object_ops
> > > i915_gem_userptr_ops = {
> > >
> > > #endif
> > >
> > > +static int
> > > +probe_range(struct mm_struct *mm, unsigned long addr, unsigned long len)
> > > +{
> > > + const unsigned long end = addr + len;
> > > + struct vm_area_struct *vma;
> > > + int ret = -EFAULT;
> > > +
> > > + mmap_read_lock(mm);
> > > + for (vma = find_vma(mm, addr); vma; vma = vma->vm_next) {
> > > + /* Check for holes, note that we also update the addr
> > > below */
> > > + if (vma->vm_start > addr)
> > > + break;
> > > +
> > > + if (vma->vm_flags & (VM_PFNMAP | VM_MIXEDMAP))
> > > + break;
> > > +
> > > + if (vma->vm_end >= end) {
> > > + ret = 0;
> > > + break;
> > > + }
> > > +
> > > + addr = vma->vm_end;
> > > + }
> > > + mmap_read_unlock(mm);
> > > +
> > > + return ret;
> > > +}
> > > +
> > > /*
> > > * Creates a new mm object that wraps some normal memory from the process
> > > * context - user memory.
> > > @@ -477,7 +505,8 @@ i915_gem_userptr_ioctl(struct drm_device *dev,
> > > }
> > >
> > > if (args->flags & ~(I915_USERPTR_READ_ONLY |
> > > - I915_USERPTR_UNSYNCHRONIZED))
> > > + I915_USERPTR_UNSYNCHRONIZED |
> > > + I915_USERPTR_PROBE))
> > > return -EINVAL;
> > >
> > > if (i915_gem_object_size_2big(args->user_size))
> > > @@ -504,6 +533,16 @@ i915_gem_userptr_ioctl(struct drm_device *dev,
> > > return -ENODEV;
> > > }
> > >
> > > + if (args->flags & I915_USERPTR_PROBE) {
> > > + /*
> > > +* Check that the range pointed to represents real struct
> > > +* pages and not iomappings (at this moment in time!)
> > > +*/
> > > + ret = probe_range(current->mm, args->user_ptr,
> > > args->user_size);
> > > + if (ret)
> > > + return ret;
> > > + }
> > > +
> > > #ifdef CONFIG_MMU_NOTIFIER
> > > obj = i915_gem_object_alloc();
> > > if (obj == NULL)
> > > diff --git a/drivers/gpu/drm/i915/i915_getparam.c
> > > b/drivers/gpu/drm/i915/i9
Re: [PATCH 2/2] drm/panel: Add Samsung S6E3FA2 DSI panel driver
Hi Alexey,
I had some gmail problems and replied to the very old driver
by Iskren, sorry for the mess.
I overall like this driver a lot. Some of Sam's comments could
be addressed especially for backlight.
I think the driver should indeed handle both the physical
displays like you do here.
On Sun, Jul 25, 2021 at 4:05 PM Alexey Minnekhanov
wrote:
> Samsung S6E3FA2 panel is amoled 1080x1920 command mode DSI
> panel used in Samsung Galaxy S5 phone. There are 2 known
> variations of panel that were shipped in this phone, and
> this driver handles both of them.
>
> Panel has built-in backlight (like all other AMOLED panels),
> controlled over DSI by some vendor specific commands, some
> of them include sending long byte sequences of what seems
> to be called "smart dimming".
>
> Signed-off-by: Alexey Minnekhanov
(...)
> +#define dsi_generic_write_seq(dsi, seq...) do {
> \
> + static const u8 d[] = { seq }; \
> + int ret;\
> + ret = mipi_dsi_generic_write(dsi, d, ARRAY_SIZE(d));\
> + if (ret < 0)\
> + return ret; \
> + } while (0)
> +
> +#define dsi_dcs_write_seq(dsi, seq...) do {\
> + static const u8 d[] = { seq }; \
> + int ret;\
> + ret = mipi_dsi_dcs_write_buffer(dsi, d, ARRAY_SIZE(d)); \
> + if (ret < 0)\
> + return ret; \
> + } while (0)
These look generic as pointed out in other mail.
> +static int s6e3fa2_dsi_dcs_read1(struct mipi_dsi_device *dsi, const u8 cmd,
> + u8 *data)
> +{
> + int ret;
> +
> + ret = mipi_dsi_dcs_read(dsi, cmd, data, 1);
> + if (ret < 0) {
> + dev_err(&dsi->dev, "could not read DCS CMD %02x\n", cmd);
> + return ret;
> + }
> + return 0;
> +}
I don't think this needs a wrapper, just call mipi_dsi_dcs_read() directly.
> +/* Panel variants */
> +#define LCD_ID_S6E3FA2 0x602813
> +#define LCD_ID_EA8064G 0x622872
Interesting use of the "vendor" byte by Samsung here. It seems they are
repurposing the non-standard MTP bytes as they seem fit.
> +/*
> + * Which AID sequence to use for each candela level.
> + * This lookup table is same for both panels.
> + */
> +static const u8 map_candela_to_aid[S6E3FA2_NUM_GAMMA_LEVELS] = {
> +0, 2, 3, 4, 6, 7, 8, 10, 11, 13, 14, 15,
> + 16, 17, 18, 20, 21, 22, 23, 24, 25, 26, 27, 28,
> + 29, 30, 31, 32, 33, 34, 35, 36, 36, 36, 36, 36,
> + 36, 36, 36, 36, 36, 36, 36, 36, 36, 36, 37, 38,
> + 39, 40, 41, 42, 43, 44, 44, 44, 44, 44, 44, 44
> +};
This and other things hints that we are dealing with the same display
controller.
> +/* Other panel drivers call these commands test_key_enable/disable */
> +static const u8 seq_s6e3fa2_test_key_en[6] = {
> + 0xf0, 0x5a, 0x5a,
> + 0xfc, 0x5a, 0x5a
> +};
0xf0 and 0xfc is obviously some "level 2 unlock" commands.
Maybe #define them as pointed out in other comments.
> +static const u8 seq_s6e3fa2_test_key_dis[6] = {
> + 0xf0, 0xa5, 0xa5,
> + 0xfc, 0xa5, 0xa5
> +};
> +static const u8 seq_ea8064g_test_key_en[6] = {
> + 0xf0, 0x5a, 0x5a,
> + 0xf1, 0x5a, 0x5a
> +};
> +static const u8 seq_ea8064g_test_key_dis[6] = {
> + 0xf1, 0xa5, 0xa5,
> + 0xf0, 0xa5, 0xa5
> +};
The use of two different registers for locking is suspicious, that
may point to different display controllers. :/
This is an icky panel, but it seems they are close enough to
be handled by the same driver IMO.
Yours,
Linus Walleij
Re: [Intel-gfx] [PATCH] drm/i915/userptr: Probe existence of backing struct pages upon creation
On Fri, 23 Jul 2021 at 18:48, Jason Ekstrand wrote:
>
> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12044
Cool, is that ready to go? i.e can we start merging the kernel + IGT side.
>
> On Fri, Jul 23, 2021 at 6:35 AM Matthew Auld wrote:
> >
> > From: Chris Wilson
> >
> > Jason Ekstrand requested a more efficient method than userptr+set-domain
> > to determine if the userptr object was backed by a complete set of pages
> > upon creation. To be more efficient than simply populating the userptr
> > using get_user_pages() (as done by the call to set-domain or execbuf),
> > we can walk the tree of vm_area_struct and check for gaps or vma not
> > backed by struct page (VM_PFNMAP). The question is how to handle
> > VM_MIXEDMAP which may be either struct page or pfn backed...
> >
> > With discrete we are going to drop support for set_domain(), so offering
> > a way to probe the pages, without having to resort to dummy batches has
> > been requested.
> >
> > v2:
> > - add new query param for the PROBE flag, so userspace can easily
> > check if the kernel supports it(Jason).
> > - use mmap_read_{lock, unlock}.
> > - add some kernel-doc.
> > v3:
> > - In the docs also mention that PROBE doesn't guarantee that the pages
> > will remain valid by the time they are actually used(Tvrtko).
> > - Add a small comment for the hole finding logic(Jason).
> > - Move the param next to all the other params which just return true.
> >
> > Testcase: igt/gem_userptr_blits/probe
> > Signed-off-by: Chris Wilson
> > Signed-off-by: Matthew Auld
> > Cc: Thomas Hellström
> > Cc: Maarten Lankhorst
> > Cc: Tvrtko Ursulin
> > Cc: Jordan Justen
> > Cc: Kenneth Graunke
> > Cc: Jason Ekstrand
> > Cc: Daniel Vetter
> > Cc: Ramalingam C
> > Reviewed-by: Tvrtko Ursulin
> > Acked-by: Kenneth Graunke
> > Reviewed-by: Jason Ekstrand
> > ---
> > drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 41 -
> > drivers/gpu/drm/i915/i915_getparam.c| 1 +
> > include/uapi/drm/i915_drm.h | 20 ++
> > 3 files changed, 61 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
> > b/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
> > index 56edfeff8c02..468a7a617fbf 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
> > @@ -422,6 +422,34 @@ static const struct drm_i915_gem_object_ops
> > i915_gem_userptr_ops = {
> >
> > #endif
> >
> > +static int
> > +probe_range(struct mm_struct *mm, unsigned long addr, unsigned long len)
> > +{
> > + const unsigned long end = addr + len;
> > + struct vm_area_struct *vma;
> > + int ret = -EFAULT;
> > +
> > + mmap_read_lock(mm);
> > + for (vma = find_vma(mm, addr); vma; vma = vma->vm_next) {
> > + /* Check for holes, note that we also update the addr below
> > */
> > + if (vma->vm_start > addr)
> > + break;
> > +
> > + if (vma->vm_flags & (VM_PFNMAP | VM_MIXEDMAP))
> > + break;
> > +
> > + if (vma->vm_end >= end) {
> > + ret = 0;
> > + break;
> > + }
> > +
> > + addr = vma->vm_end;
> > + }
> > + mmap_read_unlock(mm);
> > +
> > + return ret;
> > +}
> > +
> > /*
> > * Creates a new mm object that wraps some normal memory from the process
> > * context - user memory.
> > @@ -477,7 +505,8 @@ i915_gem_userptr_ioctl(struct drm_device *dev,
> > }
> >
> > if (args->flags & ~(I915_USERPTR_READ_ONLY |
> > - I915_USERPTR_UNSYNCHRONIZED))
> > + I915_USERPTR_UNSYNCHRONIZED |
> > + I915_USERPTR_PROBE))
> > return -EINVAL;
> >
> > if (i915_gem_object_size_2big(args->user_size))
> > @@ -504,6 +533,16 @@ i915_gem_userptr_ioctl(struct drm_device *dev,
> > return -ENODEV;
> > }
> >
> > + if (args->flags & I915_USERPTR_PROBE) {
> > + /*
> > +* Check that the range pointed to represents real struct
> > +* pages and not iomappings (at this moment in time!)
> > +*/
> > + ret = probe_range(current->mm, args->user_ptr,
> > args->user_size);
> > + if (ret)
> > + return ret;
> > + }
> > +
> > #ifdef CONFIG_MMU_NOTIFIER
> > obj = i915_gem_object_alloc();
> > if (obj == NULL)
> > diff --git a/drivers/gpu/drm/i915/i915_getparam.c
> > b/drivers/gpu/drm/i915/i915_getparam.c
> > index 24e18219eb50..bbb7cac43eb4 100644
> > --- a/drivers/gpu/drm/i915/i915_getparam.c
> > +++ b/drivers/gpu/drm/i915/i915_getparam.c
> > @@ -134,6 +134,7 @@ int i915_getparam_ioctl(struct drm_device *dev, void
> > *data,
> > case I915_PARAM_HAS_EXEC_FENCE_ARRAY:
> > case I915_PA
Re: [Intel-gfx] [PATCH 5/8] drm/i915/gem/ttm: Only call __i915_gem_object_set_pages if needed
On Fri, 23 Jul 2021 at 18:22, Jason Ekstrand wrote: > > __i915_ttm_get_pages does two things. First, it calls ttm_bo_validate() > to check the given placement and migrate the BO if needed. Then, it > updates the GEM object to match, in case the object was migrated. If > no migration occured, however, we might still have pages on the GEM > object in which case we don't need to fetch them from TTM and call > __i915_gem_object_set_pages. This hasn't been a problem before because > the primary user of __i915_ttm_get_pages is __i915_gem_object_get_pages > which only calls it if the GEM object doesn't have pages. > > However, i915_ttm_migrate also uses __i915_ttm_get_pages to do the > migration so this meant it was unsafe to call on an already populated > object. This patch checks i915_gem_object_has_pages() before trying to > __i915_gem_object_set_pages so i915_ttm_migrate is safe to call, even on > populated objects. > > Signed-off-by: Jason Ekstrand Reviewed-by: Matthew Auld
Re: [Intel-gfx] [PATCH 6/8] drm/i915/gem: Always call obj->ops->migrate unless can_migrate fails
On Fri, 23 Jul 2021 at 18:22, Jason Ekstrand wrote:
>
> Without TTM, we have no such hook so we exit early but this is fine
> because we use TTM on all LMEM platforms and, on integrated platforms,
> there is no real migration. If we do have the hook, it's better to just
> let TTM handle the migration because it knows where things are actually
> placed.
>
> This fixes a bug where i915_gem_object_migrate fails to migrate newly
> created LMEM objects. In that scenario, the object has obj->mm.region
> set to LMEM but TTM has it in SMEM because that's where all new objects
> are placed there prior to getting actual pages. When we invoke
> i915_gem_object_migrate, it exits early because, from the point of view
> of the GEM object, it's already in LMEM and no migration is needed.
> Then, when we try to pin the pages, __i915_ttm_get_pages is called
> which, unaware of our failed attempt at a migration, places the object
> in SMEM. This only happens on newly created objects because they have
> this weird state where TTM thinks they're in SMEM, GEM thinks they're in
> LMEM, and the reality is that they don't exist at all.
>
> It's better if GEM just always calls into TTM and let's TTM handle
> things. That way the lies stay better contained. Once the migration is
> complete, the object will have pages, obj->mm.region will be correct,
> and we're done lying.
>
> Signed-off-by: Jason Ekstrand
Thanks for fixing this,
Reviewed-by: Matthew Auld
> ---
> drivers/gpu/drm/i915/gem/i915_gem_object.c | 9 ++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
> b/drivers/gpu/drm/i915/gem/i915_gem_object.c
> index d09bd9bdb38ac..9d3497e1235a0 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
> @@ -607,12 +607,15 @@ int i915_gem_object_migrate(struct drm_i915_gem_object
> *obj,
> mr = i915->mm.regions[id];
> GEM_BUG_ON(!mr);
>
> - if (obj->mm.region == mr)
> - return 0;
> -
> if (!i915_gem_object_can_migrate(obj, id))
> return -EINVAL;
>
> + if (!obj->ops->migrate) {
> + if (GEM_WARN_ON(obj->mm.region != mr))
> + return -EINVAL;
> + return 0;
> + }
> +
> return obj->ops->migrate(obj, mr);
> }
>
> --
> 2.31.1
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/8] drm/i915: Migrate memory to SMEM when imported cross-device (v8)
On Fri, 23 Jul 2021 at 18:21, Jason Ekstrand wrote: > > This patch series fixes an issue with discrete graphics on Intel where we > allowed dma-buf import while leaving the object in local memory. This > breaks down pretty badly if the import happened on a different physical > device. > > v7: > - Drop "drm/i915/gem/ttm: Place new BOs in the requested region" > - Add a new "drm/i915/gem: Call i915_gem_flush_free_objects() in > i915_gem_dumb_create()" > - Misc. review feedback from Matthew Auld > v8: > - Misc. review feedback from Matthew Auld > v9: > - Replace the i915/ttm patch with two that are hopefully more correct > > Jason Ekstrand (6): > drm/i915/gem: Check object_can_migrate from object_migrate > drm/i915/gem: Refactor placement setup for i915_gem_object_create* > (v2) > drm/i915/gem: Call i915_gem_flush_free_objects() in > i915_gem_dumb_create() > drm/i915/gem: Unify user object creation (v3) > drm/i915/gem/ttm: Only call __i915_gem_object_set_pages if needed > drm/i915/gem: Always call obj->ops->migrate unless can_migrate fails > > Thomas Hellström (2): > drm/i915/gem: Correct the locking and pin pattern for dma-buf (v8) > drm/i915/gem: Migrate to system at dma-buf attach time (v7) Should I push the series? > > drivers/gpu/drm/i915/gem/i915_gem_create.c| 177 > drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c| 58 -- > drivers/gpu/drm/i915/gem/i915_gem_object.c| 20 +- > drivers/gpu/drm/i915/gem/i915_gem_object.h| 4 + > drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 13 +- > .../drm/i915/gem/selftests/i915_gem_dmabuf.c | 190 +- > .../drm/i915/gem/selftests/i915_gem_migrate.c | 15 -- > 7 files changed, 341 insertions(+), 136 deletions(-) > > -- > 2.31.1 > > ___ > Intel-gfx mailing list > intel-...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [PATCH] drm/i915/userptr: Probe existence of backing struct pages upon creation
Op 23-07-2021 om 13:34 schreef Matthew Auld:
> From: Chris Wilson
>
> Jason Ekstrand requested a more efficient method than userptr+set-domain
> to determine if the userptr object was backed by a complete set of pages
> upon creation. To be more efficient than simply populating the userptr
> using get_user_pages() (as done by the call to set-domain or execbuf),
> we can walk the tree of vm_area_struct and check for gaps or vma not
> backed by struct page (VM_PFNMAP). The question is how to handle
> VM_MIXEDMAP which may be either struct page or pfn backed...
>
> With discrete we are going to drop support for set_domain(), so offering
> a way to probe the pages, without having to resort to dummy batches has
> been requested.
>
> v2:
> - add new query param for the PROBE flag, so userspace can easily
> check if the kernel supports it(Jason).
> - use mmap_read_{lock, unlock}.
> - add some kernel-doc.
> v3:
> - In the docs also mention that PROBE doesn't guarantee that the pages
> will remain valid by the time they are actually used(Tvrtko).
> - Add a small comment for the hole finding logic(Jason).
> - Move the param next to all the other params which just return true.
>
> Testcase: igt/gem_userptr_blits/probe
> Signed-off-by: Chris Wilson
> Signed-off-by: Matthew Auld
> Cc: Thomas Hellström
> Cc: Maarten Lankhorst
> Cc: Tvrtko Ursulin
> Cc: Jordan Justen
> Cc: Kenneth Graunke
> Cc: Jason Ekstrand
> Cc: Daniel Vetter
> Cc: Ramalingam C
> Reviewed-by: Tvrtko Ursulin
> Acked-by: Kenneth Graunke
> Reviewed-by: Jason Ekstrand
> ---
> drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 41 -
> drivers/gpu/drm/i915/i915_getparam.c| 1 +
> include/uapi/drm/i915_drm.h | 20 ++
> 3 files changed, 61 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
> b/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
> index 56edfeff8c02..468a7a617fbf 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
> @@ -422,6 +422,34 @@ static const struct drm_i915_gem_object_ops
> i915_gem_userptr_ops = {
>
> #endif
>
> +static int
> +probe_range(struct mm_struct *mm, unsigned long addr, unsigned long len)
> +{
> + const unsigned long end = addr + len;
> + struct vm_area_struct *vma;
> + int ret = -EFAULT;
> +
> + mmap_read_lock(mm);
> + for (vma = find_vma(mm, addr); vma; vma = vma->vm_next) {
> + /* Check for holes, note that we also update the addr below */
> + if (vma->vm_start > addr)
> + break;
> +
> + if (vma->vm_flags & (VM_PFNMAP | VM_MIXEDMAP))
> + break;
> +
> + if (vma->vm_end >= end) {
> + ret = 0;
> + break;
> + }
> +
> + addr = vma->vm_end;
> + }
> + mmap_read_unlock(mm);
> +
> + return ret;
> +}
> +
> /*
> * Creates a new mm object that wraps some normal memory from the process
> * context - user memory.
> @@ -477,7 +505,8 @@ i915_gem_userptr_ioctl(struct drm_device *dev,
> }
>
> if (args->flags & ~(I915_USERPTR_READ_ONLY |
> - I915_USERPTR_UNSYNCHRONIZED))
> + I915_USERPTR_UNSYNCHRONIZED |
> + I915_USERPTR_PROBE))
> return -EINVAL;
>
> if (i915_gem_object_size_2big(args->user_size))
> @@ -504,6 +533,16 @@ i915_gem_userptr_ioctl(struct drm_device *dev,
> return -ENODEV;
> }
>
> + if (args->flags & I915_USERPTR_PROBE) {
> + /*
> + * Check that the range pointed to represents real struct
> + * pages and not iomappings (at this moment in time!)
> + */
> + ret = probe_range(current->mm, args->user_ptr, args->user_size);
> + if (ret)
> + return ret;
> + }
> +
> #ifdef CONFIG_MMU_NOTIFIER
> obj = i915_gem_object_alloc();
> if (obj == NULL)
> diff --git a/drivers/gpu/drm/i915/i915_getparam.c
> b/drivers/gpu/drm/i915/i915_getparam.c
> index 24e18219eb50..bbb7cac43eb4 100644
> --- a/drivers/gpu/drm/i915/i915_getparam.c
> +++ b/drivers/gpu/drm/i915/i915_getparam.c
> @@ -134,6 +134,7 @@ int i915_getparam_ioctl(struct drm_device *dev, void
> *data,
> case I915_PARAM_HAS_EXEC_FENCE_ARRAY:
> case I915_PARAM_HAS_EXEC_SUBMIT_FENCE:
> case I915_PARAM_HAS_EXEC_TIMELINE_FENCES:
> + case I915_PARAM_HAS_USERPTR_PROBE:
> /* For the time being all of these are always true;
>* if some supported hardware does not have one of these
>* features this value needs to be provided from
> diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
> index 975087553ea0..0d290535a6e5 100644
> --- a/include/uapi/drm/i915_drm.h
> +++ b/include/uapi/drm/i915_drm.h
> @@ -674,6 +674,9 @@ typ
Re: [PATCH] drm: document drm_mode_get_property
On Wednesday, July 21st, 2021 at 13:39, Daniel Vetter wrote: > I think it would be really good to link to > > https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html#modeset-base-object-abstraction > > for all the property related ioctl. That entire class vs instance > confusion is pretty common I think, which is why I even made a nice > picture about it :-) I cannot figure out how to link to that page after blindly trying a bunch of magical Sphinx invocations. I must say, links aren't RST's forte, inserting them is as intuitive as mud. Does anyone know how to do it?
Re: [Intel-gfx] [PATCH 04/10] drm/i915: move intel_context slab to direct module init/exit
On 23/07/2021 20:29, Daniel Vetter wrote:
With the global kmem_cache shrink infrastructure gone there's nothing
special and we can convert them over.
I'm doing this split up into each patch because there's quite a bit of
noise with removing the static global.slab_ce to just a
slab_ce.
Cc: Jason Ekstrand
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/gt/intel_context.c | 25 -
drivers/gpu/drm/i915/gt/intel_context.h | 3 +++
drivers/gpu/drm/i915/i915_globals.c | 2 --
drivers/gpu/drm/i915/i915_globals.h | 1 -
drivers/gpu/drm/i915/i915_pci.c | 2 ++
5 files changed, 13 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
b/drivers/gpu/drm/i915/gt/intel_context.c
index baa05fddd690..283382549a6f 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -7,7 +7,6 @@
#include "gem/i915_gem_pm.h"
#include "i915_drv.h"
-#include "i915_globals.h"
#include "i915_trace.h"
#include "intel_context.h"
@@ -15,14 +14,11 @@
#include "intel_engine_pm.h"
#include "intel_ring.h"
-static struct i915_global_context {
- struct i915_global base;
- struct kmem_cache *slab_ce;
-} global;
+struct kmem_cache *slab_ce;
static struct intel_context *intel_context_alloc(void)
{
- return kmem_cache_zalloc(global.slab_ce, GFP_KERNEL);
+ return kmem_cache_zalloc(slab_ce, GFP_KERNEL);
}
static void rcu_context_free(struct rcu_head *rcu)
@@ -30,7 +26,7 @@ static void rcu_context_free(struct rcu_head *rcu)
struct intel_context *ce = container_of(rcu, typeof(*ce), rcu);
trace_intel_context_free(ce);
- kmem_cache_free(global.slab_ce, ce);
+ kmem_cache_free(slab_ce, ce);
}
void intel_context_free(struct intel_context *ce)
@@ -410,22 +406,17 @@ void intel_context_fini(struct intel_context *ce)
i915_active_fini(&ce->active);
}
-static void i915_global_context_exit(void)
+void i915_context_module_exit(void)
{
- kmem_cache_destroy(global.slab_ce);
+ kmem_cache_destroy(slab_ce);
}
-static struct i915_global_context global = { {
- .exit = i915_global_context_exit,
-} };
-
-int __init i915_global_context_init(void)
+int __init i915_context_module_init(void)
{
- global.slab_ce = KMEM_CACHE(intel_context, SLAB_HWCACHE_ALIGN);
- if (!global.slab_ce)
+ slab_ce = KMEM_CACHE(intel_context, SLAB_HWCACHE_ALIGN);
+ if (!slab_ce)
return -ENOMEM;
- i915_global_register(&global.base);
return 0;
}
diff --git a/drivers/gpu/drm/i915/gt/intel_context.h b/drivers/gpu/drm/i915/gt/intel_context.h
index 974ef85320c2..a0ca82e3c40d 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.h
+++ b/drivers/gpu/drm/i915/gt/intel_context.h
@@ -30,6 +30,9 @@ void intel_context_init(struct intel_context *ce,
struct intel_engine_cs *engine);
void intel_context_fini(struct intel_context *ce);
+void i915_context_module_exit(void);
+int i915_context_module_init(void);
+
struct intel_context *
intel_context_create(struct intel_engine_cs *engine);
diff --git a/drivers/gpu/drm/i915/i915_globals.c b/drivers/gpu/drm/i915/i915_globals.c
index 3de7cf22ec76..d36eb7dc40aa 100644
--- a/drivers/gpu/drm/i915/i915_globals.c
+++ b/drivers/gpu/drm/i915/i915_globals.c
@@ -7,7 +7,6 @@
#include
#include
-#include "gem/i915_gem_context.h"
#include "gem/i915_gem_object.h"
#include "i915_globals.h"
#include "i915_request.h"
@@ -32,7 +31,6 @@ static void __i915_globals_cleanup(void)
}
static __initconst int (* const initfn[])(void) = {
- i915_global_context_init,
i915_global_gem_context_init,
i915_global_objects_init,
i915_global_request_init,
diff --git a/drivers/gpu/drm/i915/i915_globals.h
b/drivers/gpu/drm/i915/i915_globals.h
index d80901ba75e3..60daa738a188 100644
--- a/drivers/gpu/drm/i915/i915_globals.h
+++ b/drivers/gpu/drm/i915/i915_globals.h
@@ -23,7 +23,6 @@ int i915_globals_init(void);
void i915_globals_exit(void);
/* constructors */
-int i915_global_context_init(void);
int i915_global_gem_context_init(void);
int i915_global_objects_init(void);
int i915_global_request_init(void);
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index f9527269e30a..266618157775 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -33,6 +33,7 @@
#include "i915_active.h"
#include "i915_buddy.h"
#include "i915_drv.h"
+#include "gem/i915_gem_context.h"
It's a bit ugly to go to a design where i915_pci.c has to include so
many random parts of i915. IMO for a complex driver like i915,
compartmentalizing so much knowledge about the internals was better
inside the globals layer.
Maybe add a cover letter to explain the perceived pros and cons and
thinking in general?
Regards,
Tvrtko
#include "i915_perf.h"
Re: [RFC 6/8] drm: Document fdinfo format specification
On 23/07/2021 17:43, Daniel Stone wrote: Hi Tvrtko, Thanks for typing this up! On Thu, 15 Jul 2021 at 10:18, Tvrtko Ursulin wrote: +Mandatory fully standardised keys +- + +- drm-driver: + +String shall contain a fixed string uniquely identified the driver handling +the device in question. For example name of the respective kernel module. I think let's be more prescriptive and just say that it is the module name. I liked the drm_driver.name the other Daniel made so I'll go with that. +Optional fully standardised keys + + +- drm-pdev: + +For PCI devices this should contain the PCI slot address of the device in +question. How about just major:minor of the DRM render node device it's attached to? I don't have a strong opinion on this one. I can add it, but might keep the drm-dev tag under the optional list because it is handy for intel_gpu_top multi-device support. Or maybe the lookup to pci device is easier than I think now so okay, on my todo list to check. +- drm-client-id: + +Unique value relating to the open DRM file descriptor used to distinguish +duplicated and shared file descriptors. Conceptually the value should map 1:1 +to the in kernel representation of `struct drm_file` instances. + +Uniqueness of the value shall be either globally unique, or unique within the +scope of each device, in which case `drm-pdev` shall be present as well. + +Userspace should make sure to not double account any usage statistics by using +the above described criteria in order to associate data to individual clients. + +- drm-engine-: ns + +GPUs usually contain multiple execution engines. Each shall be given a stable +and unique name (str), with possible values documented in the driver specific +documentation. + +Value shall be in specified time units which the respective GPU engine spent +busy executing workloads belonging to this client. + +Values are not required to be constantly monotonic if it makes the driver +implementation easier, but are required to catch up with the previously reported +larger value within a reasonable period. Upon observing a value lower than what +was previously read, userspace is expected to stay with that larger previous +value until a monotonic update is seen. Yeah, that would work well for Mali/Panfrost. We can queue multiple jobs in the hardware, which can either be striped across multiple cores with an affinity mask (e.g. 3 cores for your client and 1 for your compositor), or picked according to priority, or ... The fine-grained performance counters (e.g. time spent waiting for sampler) are only GPU-global. So if you have two jobs running simultaneously, you have no idea who's responsible for what. But it does give us coarse-grained counters which are accounted per-job-slot, including exactly this metric: amount of 'GPU time' (whatever that means) occupied by that job slot during the sampling period. So we could support that nicely if we fenced job-slot updates with register reads/writes. Something I'm missing though is how we enable this information. Seems like it would be best to either only do it whilst fdinfo is open (and re-read it whenever you need an update), or on a per-driver sysfs toggle, or ... ? Presumably there is non-trivial cost for querying this data on your driver? Would it be workable to enable tracking on first use and stop some time after last? Just a thought which may have significant downsides from driver to driver. +- drm-memory-: [KiB|MiB] + +Each possible memory type which can be used to store buffer objects by the +GPU in question shall be given a stable and unique name to be returned as the +string here. + +Value shall reflect the amount of storage currently consumed by the buffer +object belong to this client, in the respective memory region. + +Default unit shall be bytes with optional unit specifiers of 'KiB' or 'MiB' +indicating kibi- or mebi-bytes. I'm a bit wary of the accounting here. Is it buffer allocations originating from the client, in which case it conceptually clashes with gralloc? Is it the client which last wrote to the buffer? The client with the oldest open handle to the buffer? Other? Haven't looked into AMD code here so know what they export. Gralloc allocates buffer from it's own drm client and shares them or it is just a library which runs from a client context? Regards, Tvrtko
Re: [RFC 6/8] drm: Document fdinfo format specification
On 23/07/2021 18:45, Nieto, David M wrote: [AMD Official Use Only] I just want to make a comment that with this approach (the ns) calculating the percentage will take at least two reads of the fdinfo per pid over some time. Some engines may be able to provide a single shot percentage usage over an internal integration period. That is, for example, what we currently have implemented for that exact reason. I'd like to propose that we add an optional set of fields for this. Yes it is already like that in the text I've sent out. Because I was unclear how the amdgpu accounting works I called out for you guys to fill in the blanks in the last patch: """ Opens: * Does it work for AMD? * What are the semantics of AMD engine utilisation reported in percents? Can it align with what i915 does or needs to document the alternative in the specification document? """ """ -- drm-engine-: ns +- drm-engine-: [ns|%] ... +Where time unit is given as a percentage...[AMD folks to fill the semantics +and interpretation of that]... """ So if cumulative nanoseconds definitely do not work for you, could you please fill in those blanks? Also, I may have missed a message, but why did we remove the timstamp? It is needed for accurate measurements of engine usage. Hm I did not remove anything - I only renamed some of the fields output from amdgpu fdinfo. Regards, Tvrtko David *From:* Daniel Vetter *Sent:* Friday, July 23, 2021 9:47 AM *To:* Daniel Stone *Cc:* Tvrtko Ursulin ; intel-gfx ; Tvrtko Ursulin ; Koenig, Christian ; dri-devel ; Nieto, David M *Subject:* Re: [RFC 6/8] drm: Document fdinfo format specification On Fri, Jul 23, 2021 at 05:43:01PM +0100, Daniel Stone wrote: Hi Tvrtko, Thanks for typing this up! On Thu, 15 Jul 2021 at 10:18, Tvrtko Ursulin wrote: > +Mandatory fully standardised keys > +- > + > +- drm-driver: > + > +String shall contain a fixed string uniquely identified the driver handling > +the device in question. For example name of the respective kernel module. I think let's be more prescriptive and just say that it is the module name. Just a quick comment on this one. drm_driver.name is already uapi, so let's please not invent a new one. The shared code should probably make sure drivers don't get this wrong. Maybe good if we document the getverion ioctl, which also exposes this, and then link between the two. -Daniel > +Optional fully standardised keys > + > + > +- drm-pdev: > + > +For PCI devices this should contain the PCI slot address of the device in > +question. How about just major:minor of the DRM render node device it's attached to? > +- drm-client-id: > + > +Unique value relating to the open DRM file descriptor used to distinguish > +duplicated and shared file descriptors. Conceptually the value should map 1:1 > +to the in kernel representation of `struct drm_file` instances. > + > +Uniqueness of the value shall be either globally unique, or unique within the > +scope of each device, in which case `drm-pdev` shall be present as well. > + > +Userspace should make sure to not double account any usage statistics by using > +the above described criteria in order to associate data to individual clients. > + > +- drm-engine-: ns > + > +GPUs usually contain multiple execution engines. Each shall be given a stable > +and unique name (str), with possible values documented in the driver specific > +documentation. > + > +Value shall be in specified time units which the respective GPU engine spent > +busy executing workloads belonging to this client. > + > +Values are not required to be constantly monotonic if it makes the driver > +implementation easier, but are required to catch up with the previously reported > +larger value within a reasonable period. Upon observing a value lower than what > +was previously read, userspace is expected to stay with that larger previous > +value until a monotonic update is seen. Yeah, that would work well for Mali/Panfrost. We can queue multiple jobs in the hardware, which can either be striped across multiple cores with an affinity mask (e.g. 3 cores for your client and 1 for your compositor), or picked according to priority, or ... The fine-grained performance counters (e.g. time spent waiting for sampler) are only GPU-global. So if you have two jobs running simultaneously, you have no idea who's responsible for what. But it does give us coarse-grained counters which are accounted per-job-slot, including exactly this metric: amount of 'GPU time' (whatever that means) occupied by that job slot during the sampling period. So we could support that nicely if we fenced job-slot updates with register reads/writes. Something I'm missing though is how we enable this information. Seems like it would be best to either only do it whilst fdinfo is open (and re-read it whenever you n
Re: [PATCH v3 3/3] drm/panel-simple: add Gopher 2b LCD panel
Hi Artjom,
Le lun., juil. 26 2021 at 01:15:27 +0300, Artjom Vejsel
a écrit :
The Gopher 2b LCD panel is used in Gopher 2b handhelds.
It's simple panel with NewVision NV3047 driver, but SPI lines are not
connected.
It has no specific name, since it's unique to that handhelds.
lot name at AliExpress: 4.3 inch 40PIN TFT LCD Screen COG NV3047
Drive IC 480(RGB)*272 No Touch 24Bit RGB Interface
From what I gathered the Gopher2's LCD panel is the exact same that is
inside the RS-07 handheld. According to the teardown (in [1]), the
RS-07 panel is a Amelin AML043056B0-40 (see [2]).
Could you verify that? According to the photos, the product code is
written on the flexible connector.
If that's the case, instead of using the
"qishenglong,gopher2b-lcd-panel" compatible string, could you use
"amelin,aml043056b0-40"?
Cheers,
-Paul
[1]: https://steward-fu.github.io/website/handheld/rs07/teardown.htm
[2]: http://www.amelin.com.cn/en/h-pd-355.html
Signed-off-by: Artjom Vejsel
---
drivers/gpu/drm/panel/panel-simple.c | 43
1 file changed, 43 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 9b286bdf..6b69c0c70814 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -3563,6 +3563,46 @@ static const struct panel_desc qd43003c0_40 = {
.bus_format = MEDIA_BUS_FMT_RGB888_1X24,
};
+static const struct drm_display_mode
qishenglong_gopher2b_lcd_panel_modes[] = {
+ { /* 60 Hz */
+ .clock = 10800,
+ .hdisplay = 480,
+ .hsync_start = 480 + 77,
+ .hsync_end = 480 + 77 + 41,
+ .htotal = 480 + 77 + 41 + 2,
+ .vdisplay = 272,
+ .vsync_start = 272 + 16,
+ .vsync_end = 272 + 16 + 10,
+ .vtotal = 272 + 16 + 10 + 2,
+ .flags = DRM_MODE_FLAG_NVSYNC | DRM_MODE_FLAG_NHSYNC,
+ },
+ { /* 50 Hz */
+ .clock = 10800,
+ .hdisplay = 480,
+ .hsync_start = 480 + 17,
+ .hsync_end = 480 + 17 + 41,
+ .htotal = 480 + 17 + 41 + 2,
+ .vdisplay = 272,
+ .vsync_start = 272 + 116,
+ .vsync_end = 272 + 116 + 10,
+ .vtotal = 272 + 116 + 10 + 2,
+ .flags = DRM_MODE_FLAG_NVSYNC | DRM_MODE_FLAG_NHSYNC,
+ },
+};
+
+static const struct panel_desc qishenglong_gopher2b_lcd_panel = {
+ .modes = qishenglong_gopher2b_lcd_panel_modes,
+ .num_modes = ARRAY_SIZE(qishenglong_gopher2b_lcd_panel_modes),
+ .bpc = 8,
+ .size = {
+ .width = 95,
+ .height = 54,
+ },
+ .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
+ .bus_flags = DRM_BUS_FLAG_DE_HIGH |
DRM_BUS_FLAG_PIXDATA_SAMPLE_NEGEDGE,
+ .connector_type = DRM_MODE_CONNECTOR_DPI,
+};
+
static const struct display_timing rocktech_rk070er9427_timing = {
.pixelclock = { 2640, 3330, 4680 },
.hactive = { 800, 800, 800 },
@@ -4651,6 +4691,9 @@ static const struct of_device_id
platform_of_match[] = {
}, {
.compatible = "qiaodian,qd43003c0-40",
.data = &qd43003c0_40,
+ }, {
+ .compatible = "qishenglong,gopher2b-lcd-panel",
+ .data = &qishenglong_gopher2b_lcd_panel,
}, {
.compatible = "rocktech,rk070er9427",
.data = &rocktech_rk070er9427,
--
2.32.0
Re: [PATCH 0/3] add checks against divide error
On Mon, Jul 26, 2021 at 4:18 AM Sam Ravnborg wrote: > > Hi Zheyu, > > On Sun, Jul 25, 2021 at 02:10:51AM +, Zheyu Ma wrote: > > Zheyu Ma (3): > > video: fbdev: kyro: add a check against divide error > > video: fbdev: riva: add a check against divide error > > video: fbdev: asiliantfb: add a check against divide error > > I would prefer something a bit more descriptive - like: > > video: fbdev: : Error out if pixclk equals zero > > Please respin so we have something like the above. > I looked briefly at the patches, they looked fine. Thanks for your valuable comments, I will re-edit the commit log and send the patches. Regards, Zheyu Ma
[PATCH v2 0/3] Error out if 'pixclock' equals zero
Zheyu Ma (3): video: fbdev: asiliantfb: Error out if 'pixclock' equals zero video: fbdev: kyro: Error out if 'pixclock' equals zero video: fbdev: riva: Error out if 'pixclock' equals zero drivers/video/fbdev/asiliantfb.c | 3 +++ drivers/video/fbdev/kyro/fbdev.c | 3 +++ drivers/video/fbdev/riva/fbdev.c | 3 +++ 3 files changed, 9 insertions(+) -- 2.17.6
[PATCH v2 1/3] video: fbdev: asiliantfb: Error out if 'pixclock' equals zero
The userspace program could pass any values to the driver through
ioctl() interface. If the driver doesn't check the value of 'pixclock',
it may cause divide error.
Fix this by checking whether 'pixclock' is zero first.
The following log reveals it:
[ 43.861711] divide error: [#1] PREEMPT SMP KASAN PTI
[ 43.861737] CPU: 2 PID: 11764 Comm: i740 Not tainted
5.14.0-rc2-00513-gac532c9bbcfb-dirty #224
[ 43.861756] RIP: 0010:asiliantfb_check_var+0x4e/0x730
[ 43.861843] Call Trace:
[ 43.861848] ? asiliantfb_remove+0x190/0x190
[ 43.861858] fb_set_var+0x2e4/0xeb0
[ 43.861866] ? fb_blank+0x1a0/0x1a0
[ 43.861873] ? lock_acquire+0x1ef/0x530
[ 43.861884] ? lock_release+0x810/0x810
[ 43.861892] ? lock_is_held_type+0x100/0x140
[ 43.861903] ? ___might_sleep+0x1ee/0x2d0
[ 43.861914] ? __mutex_lock+0x620/0x1190
[ 43.861921] ? do_fb_ioctl+0x313/0x700
[ 43.861929] ? mutex_lock_io_nested+0xfa0/0xfa0
[ 43.861936] ? __this_cpu_preempt_check+0x1d/0x30
[ 43.861944] ? _raw_spin_unlock_irqrestore+0x46/0x60
[ 43.861952] ? lockdep_hardirqs_on+0x59/0x100
[ 43.861959] ? _raw_spin_unlock_irqrestore+0x46/0x60
[ 43.861967] ? trace_hardirqs_on+0x6a/0x1c0
[ 43.861978] do_fb_ioctl+0x31e/0x700
Signed-off-by: Zheyu Ma
---
Changes in v2:
- Make commit log more descriptive
---
drivers/video/fbdev/asiliantfb.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/video/fbdev/asiliantfb.c b/drivers/video/fbdev/asiliantfb.c
index 3e006da47752..84c56f525889 100644
--- a/drivers/video/fbdev/asiliantfb.c
+++ b/drivers/video/fbdev/asiliantfb.c
@@ -227,6 +227,9 @@ static int asiliantfb_check_var(struct fb_var_screeninfo
*var,
{
unsigned long Ftarget, ratio, remainder;
+ if (!var->pixclock)
+ return -EINVAL;
+
ratio = 100 / var->pixclock;
remainder = 100 % var->pixclock;
Ftarget = 100 * ratio + (100 * remainder) / var->pixclock;
--
2.17.6
[PATCH v2 2/3] video: fbdev: kyro: Error out if 'pixclock' equals zero
The userspace program could pass any values to the driver through
ioctl() interface. if the driver doesn't check the value of 'pixclock',
it may cause divide error because the value of 'lineclock' and
'frameclock' will be zero.
Fix this by checking whether 'pixclock' is zero in kyrofb_check_var().
The following log reveals it:
[ 103.073930] divide error: [#1] PREEMPT SMP KASAN PTI
[ 103.073942] CPU: 4 PID: 12483 Comm: syz-executor Not tainted
5.14.0-rc2-00478-g2734d6c1b1a0-dirty #118
[ 103.073959] RIP: 0010:kyrofb_set_par+0x316/0xc80
[ 103.074045] Call Trace:
[ 103.074048] ? ___might_sleep+0x1ee/0x2d0
[ 103.074060] ? kyrofb_ioctl+0x330/0x330
[ 103.074069] fb_set_var+0x5bf/0xeb0
[ 103.074078] ? fb_blank+0x1a0/0x1a0
[ 103.074085] ? lock_acquire+0x3bd/0x530
[ 103.074094] ? lock_release+0x810/0x810
[ 103.074103] ? ___might_sleep+0x1ee/0x2d0
[ 103.074114] ? __mutex_lock+0x620/0x1190
[ 103.074126] ? trace_hardirqs_on+0x6a/0x1c0
[ 103.074137] do_fb_ioctl+0x31e/0x700
[ 103.074144] ? fb_getput_cmap+0x280/0x280
[ 103.074152] ? rcu_read_lock_sched_held+0x11/0x80
[ 103.074162] ? rcu_read_lock_sched_held+0x11/0x80
[ 103.074171] ? __sanitizer_cov_trace_switch+0x67/0xf0
[ 103.074181] ? __sanitizer_cov_trace_const_cmp2+0x20/0x80
[ 103.074191] ? do_vfs_ioctl+0x14b/0x16c0
[ 103.074199] ? vfs_fileattr_set+0xb60/0xb60
[ 103.074207] ? rcu_read_lock_sched_held+0x11/0x80
[ 103.074216] ? lock_release+0x483/0x810
[ 103.074224] ? __fget_files+0x217/0x3d0
[ 103.074234] ? __fget_files+0x239/0x3d0
[ 103.074243] ? do_fb_ioctl+0x700/0x700
[ 103.074250] fb_ioctl+0xe6/0x130
Signed-off-by: Zheyu Ma
---
Changes in v2:
- Make commmit log more descriptive
---
drivers/video/fbdev/kyro/fbdev.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/video/fbdev/kyro/fbdev.c b/drivers/video/fbdev/kyro/fbdev.c
index 8fbde92ae8b9..6db7e5e83f11 100644
--- a/drivers/video/fbdev/kyro/fbdev.c
+++ b/drivers/video/fbdev/kyro/fbdev.c
@@ -394,6 +394,9 @@ static int kyrofb_check_var(struct fb_var_screeninfo *var,
struct fb_info *info)
{
struct kyrofb_info *par = info->par;
+ if (!var->pixclock)
+ return -EINVAL;
+
if (var->bits_per_pixel != 16 && var->bits_per_pixel != 32) {
printk(KERN_WARNING "kyrofb: depth not supported: %u\n",
var->bits_per_pixel);
return -EINVAL;
--
2.17.6
[PATCH v2 3/3] video: fbdev: riva: Error out if 'pixclock' equals zero
The userspace program could pass any values to the driver through
ioctl() interface. If the driver doesn't check the value of 'pixclock',
it may cause divide error.
Fix this by checking whether 'pixclock' is zero first.
The following log reveals it:
[ 33.396850] divide error: [#1] PREEMPT SMP KASAN PTI
[ 33.396864] CPU: 5 PID: 11754 Comm: i740 Not tainted
5.14.0-rc2-00513-gac532c9bbcfb-dirty #222
[ 33.396883] RIP: 0010:riva_load_video_mode+0x417/0xf70
[ 33.396969] Call Trace:
[ 33.396973] ? debug_smp_processor_id+0x1c/0x20
[ 33.396984] ? tick_nohz_tick_stopped+0x1a/0x90
[ 33.396996] ? rivafb_copyarea+0x3c0/0x3c0
[ 33.397003] ? wake_up_klogd.part.0+0x99/0xd0
[ 33.397014] ? vprintk_emit+0x110/0x4b0
[ 33.397024] ? vprintk_default+0x26/0x30
[ 33.397033] ? vprintk+0x9c/0x1f0
[ 33.397041] ? printk+0xba/0xed
[ 33.397054] ? record_print_text.cold+0x16/0x16
[ 33.397063] ? __kasan_check_read+0x11/0x20
[ 33.397074] ? profile_tick+0xc0/0x100
[ 33.397084] ? __sanitizer_cov_trace_const_cmp4+0x24/0x80
[ 33.397094] ? riva_set_rop_solid+0x2a0/0x2a0
[ 33.397102] rivafb_set_par+0xbe/0x610
[ 33.397111] ? riva_set_rop_solid+0x2a0/0x2a0
[ 33.397119] fb_set_var+0x5bf/0xeb0
[ 33.397127] ? fb_blank+0x1a0/0x1a0
[ 33.397134] ? lock_acquire+0x1ef/0x530
[ 33.397143] ? lock_release+0x810/0x810
[ 33.397151] ? lock_is_held_type+0x100/0x140
[ 33.397159] ? ___might_sleep+0x1ee/0x2d0
[ 33.397170] ? __mutex_lock+0x620/0x1190
[ 33.397180] ? trace_hardirqs_on+0x6a/0x1c0
[ 33.397190] do_fb_ioctl+0x31e/0x700
Signed-off-by: Zheyu Ma
---
Changes in v2:
- Make commit log more descriptive
---
drivers/video/fbdev/riva/fbdev.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/video/fbdev/riva/fbdev.c b/drivers/video/fbdev/riva/fbdev.c
index 4b0433cb..84d5e23ad7d3 100644
--- a/drivers/video/fbdev/riva/fbdev.c
+++ b/drivers/video/fbdev/riva/fbdev.c
@@ -1084,6 +1084,9 @@ static int rivafb_check_var(struct fb_var_screeninfo
*var, struct fb_info *info)
int mode_valid = 0;
NVTRACE_ENTER();
+ if (!var->pixclock)
+ return -EINVAL;
+
switch (var->bits_per_pixel) {
case 1 ... 8:
var->red.offset = var->green.offset = var->blue.offset = 0;
--
2.17.6
Re: [Intel-gfx] [PATCH 28/30] drm/i915: rename/remove CNL registers
On Fri, Jul 23, 2021 at 05:11:12PM -0700, Lucas De Marchi wrote: > Remove registers that are not used anymore due to CNL removal and rename > those that are. > > Signed-off-by: Lucas De Marchi Reviewed-by: Rodrigo Vivi > --- > drivers/gpu/drm/i915/i915_reg.h | 192 ++- > drivers/gpu/drm/i915/intel_device_info.c | 2 +- > 2 files changed, 48 insertions(+), 146 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h > index 8782d1723254..925cbdb53712 100644 > --- a/drivers/gpu/drm/i915/i915_reg.h > +++ b/drivers/gpu/drm/i915/i915_reg.h > @@ -1877,7 +1877,7 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg) > #define BXT_PORT_CL1CM_DW30(phy) _BXT_PHY((phy), _PORT_CL1CM_DW30_BC) > > /* > - * CNL/ICL Port/COMBO-PHY Registers > + * ICL Port/COMBO-PHY Registers > */ > #define _ICL_COMBOPHY_A 0x162000 > #define _ICL_COMBOPHY_B 0x6C000 > @@ -1891,11 +1891,10 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg) > _RKL_COMBOPHY_D, \ > _ADL_COMBOPHY_E) > > -/* CNL/ICL Port CL_DW registers */ > +/* ICL Port CL_DW registers */ > #define _ICL_PORT_CL_DW(dw, phy) (_ICL_COMBOPHY(phy) + \ >4 * (dw)) > > -#define CNL_PORT_CL1CM_DW5 _MMIO(0x162014) > #define ICL_PORT_CL_DW5(phy) _MMIO(_ICL_PORT_CL_DW(5, phy)) > #define CL_POWER_DOWN_ENABLE (1 << 4) > #define SUS_CLOCK_CONFIG (3 << 0) > @@ -1920,19 +1919,16 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg) > #define ICL_PORT_CL_DW12(phy)_MMIO(_ICL_PORT_CL_DW(12, phy)) > #define ICL_LANE_ENABLE_AUX(1 << 0) > > -/* CNL/ICL Port COMP_DW registers */ > +/* ICL Port COMP_DW registers */ > #define _ICL_PORT_COMP 0x100 > #define _ICL_PORT_COMP_DW(dw, phy) (_ICL_COMBOPHY(phy) + \ >_ICL_PORT_COMP + 4 * (dw)) > > -#define CNL_PORT_COMP_DW0_MMIO(0x162100) > #define ICL_PORT_COMP_DW0(phy) _MMIO(_ICL_PORT_COMP_DW(0, phy)) > #define COMP_INIT (1 << 31) > > -#define CNL_PORT_COMP_DW1_MMIO(0x162104) > #define ICL_PORT_COMP_DW1(phy) _MMIO(_ICL_PORT_COMP_DW(1, phy)) > > -#define CNL_PORT_COMP_DW3_MMIO(0x16210c) > #define ICL_PORT_COMP_DW3(phy) _MMIO(_ICL_PORT_COMP_DW(3, phy)) > #define PROCESS_INFO_DOT_0 (0 << 26) > #define PROCESS_INFO_DOT_1 (1 << 26) > @@ -1948,38 +1944,11 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg) > #define ICL_PORT_COMP_DW8(phy) _MMIO(_ICL_PORT_COMP_DW(8, phy)) > #define IREFGEN(1 << 24) > > -#define CNL_PORT_COMP_DW9_MMIO(0x162124) > #define ICL_PORT_COMP_DW9(phy) _MMIO(_ICL_PORT_COMP_DW(9, phy)) > > -#define CNL_PORT_COMP_DW10 _MMIO(0x162128) > #define ICL_PORT_COMP_DW10(phy) _MMIO(_ICL_PORT_COMP_DW(10, > phy)) > > -/* CNL/ICL Port PCS registers */ > -#define _CNL_PORT_PCS_DW1_GRP_AE 0x162304 > -#define _CNL_PORT_PCS_DW1_GRP_B 0x162384 > -#define _CNL_PORT_PCS_DW1_GRP_C 0x162B04 > -#define _CNL_PORT_PCS_DW1_GRP_D 0x162B84 > -#define _CNL_PORT_PCS_DW1_GRP_F 0x162A04 > -#define _CNL_PORT_PCS_DW1_LN0_AE 0x162404 > -#define _CNL_PORT_PCS_DW1_LN0_B 0x162604 > -#define _CNL_PORT_PCS_DW1_LN0_C 0x162C04 > -#define _CNL_PORT_PCS_DW1_LN0_D 0x162E04 > -#define _CNL_PORT_PCS_DW1_LN0_F 0x162804 > -#define CNL_PORT_PCS_DW1_GRP(phy)_MMIO(_PICK(phy, \ > - _CNL_PORT_PCS_DW1_GRP_AE, \ > - _CNL_PORT_PCS_DW1_GRP_B, \ > - _CNL_PORT_PCS_DW1_GRP_C, \ > - _CNL_PORT_PCS_DW1_GRP_D, \ > - _CNL_PORT_PCS_DW1_GRP_AE, \ > - _CNL_PORT_PCS_DW1_GRP_F)) > -#define CNL_PORT_PCS_DW1_LN0(phy)_MMIO(_PICK(phy, \ > - _CNL_PORT_PCS_DW1_LN0_AE, \ > - _CNL_PORT_PCS_DW1_LN0_B, \ > - _CNL_PORT_PCS_DW1_LN0_C, \ > - _CNL_PORT_PCS_DW1_LN0_D, \ > - _CNL_PORT_PCS_DW1_LN0_AE, \ > - _CNL_PORT_PCS_DW1_LN0_F)) > - > +/* ICL Port PCS registers */ > #define _ICL_PORT_PCS_AUX0x300 > #define _ICL_PORT_PCS_GRP0x600 > #define _ICL_PORT_PCS_LN(ln)
Re: [Intel-gfx] [PATCH 27/30] drm/i915: remove GRAPHICS_VER == 10
On Fri, Jul 23, 2021 at 05:11:11PM -0700, Lucas De Marchi wrote:
> Replace all remaining handling of GRAPHICS_VER {==,>=} 10 with
> {==,>=} 11. With the removal of CNL, there is no platform with graphics
> version equals 10.
>
> Signed-off-by: Lucas De Marchi
Reviewed-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/gem/i915_gem_stolen.c| 1 -
> drivers/gpu/drm/i915/gt/debugfs_gt_pm.c | 10 ++---
> drivers/gpu/drm/i915/gt/intel_engine_cs.c | 3 --
> drivers/gpu/drm/i915/gt/intel_ggtt.c | 4 +-
> .../gpu/drm/i915/gt/intel_gt_clock_utils.c| 10 ++---
> drivers/gpu/drm/i915/gt/intel_gtt.c | 6 +--
> drivers/gpu/drm/i915/gt/intel_lrc.c | 42 +--
> drivers/gpu/drm/i915/gt/intel_rc6.c | 2 +-
> drivers/gpu/drm/i915/gt/intel_rps.c | 4 +-
> drivers/gpu/drm/i915/gt/intel_sseu_debugfs.c | 6 +--
> drivers/gpu/drm/i915/gvt/gtt.c| 2 +-
> drivers/gpu/drm/i915/i915_debugfs.c | 6 +--
> drivers/gpu/drm/i915/i915_drv.h | 2 +-
> drivers/gpu/drm/i915/i915_perf.c | 21 --
> drivers/gpu/drm/i915/intel_device_info.c | 4 +-
> 15 files changed, 37 insertions(+), 86 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
> b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
> index 90708de27684..ddd37ccb1362 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
> @@ -447,7 +447,6 @@ static int i915_gem_init_stolen(struct
> intel_memory_region *mem)
> break;
> case 8:
> case 9:
> - case 10:
> if (IS_LP(i915))
> chv_get_stolen_reserved(i915, uncore,
> &reserved_base, &reserved_size);
> diff --git a/drivers/gpu/drm/i915/gt/debugfs_gt_pm.c
> b/drivers/gpu/drm/i915/gt/debugfs_gt_pm.c
> index 4270b5a34a83..d6f5836396f8 100644
> --- a/drivers/gpu/drm/i915/gt/debugfs_gt_pm.c
> +++ b/drivers/gpu/drm/i915/gt/debugfs_gt_pm.c
> @@ -437,20 +437,20 @@ static int frequency_show(struct seq_file *m, void
> *unused)
> max_freq = (IS_GEN9_LP(i915) ? rp_state_cap >> 0 :
> rp_state_cap >> 16) & 0xff;
> max_freq *= (IS_GEN9_BC(i915) ||
> - GRAPHICS_VER(i915) >= 10 ? GEN9_FREQ_SCALER : 1);
> + GRAPHICS_VER(i915) >= 11 ? GEN9_FREQ_SCALER : 1);
> seq_printf(m, "Lowest (RPN) frequency: %dMHz\n",
> intel_gpu_freq(rps, max_freq));
>
> max_freq = (rp_state_cap & 0xff00) >> 8;
> max_freq *= (IS_GEN9_BC(i915) ||
> - GRAPHICS_VER(i915) >= 10 ? GEN9_FREQ_SCALER : 1);
> + GRAPHICS_VER(i915) >= 11 ? GEN9_FREQ_SCALER : 1);
> seq_printf(m, "Nominal (RP1) frequency: %dMHz\n",
> intel_gpu_freq(rps, max_freq));
>
> max_freq = (IS_GEN9_LP(i915) ? rp_state_cap >> 16 :
> rp_state_cap >> 0) & 0xff;
> max_freq *= (IS_GEN9_BC(i915) ||
> - GRAPHICS_VER(i915) >= 10 ? GEN9_FREQ_SCALER : 1);
> + GRAPHICS_VER(i915) >= 11 ? GEN9_FREQ_SCALER : 1);
> seq_printf(m, "Max non-overclocked (RP0) frequency: %dMHz\n",
> intel_gpu_freq(rps, max_freq));
> seq_printf(m, "Max overclocked frequency: %dMHz\n",
> @@ -500,7 +500,7 @@ static int llc_show(struct seq_file *m, void *data)
>
> min_gpu_freq = rps->min_freq;
> max_gpu_freq = rps->max_freq;
> - if (IS_GEN9_BC(i915) || GRAPHICS_VER(i915) >= 10) {
> + if (IS_GEN9_BC(i915) || GRAPHICS_VER(i915) >= 11) {
> /* Convert GT frequency to 50 HZ units */
> min_gpu_freq /= GEN9_FREQ_SCALER;
> max_gpu_freq /= GEN9_FREQ_SCALER;
> @@ -518,7 +518,7 @@ static int llc_show(struct seq_file *m, void *data)
> intel_gpu_freq(rps,
> (gpu_freq *
> (IS_GEN9_BC(i915) ||
> - GRAPHICS_VER(i915) >= 10 ?
> + GRAPHICS_VER(i915) >= 11 ?
> GEN9_FREQ_SCALER : 1))),
> ((ia_freq >> 0) & 0xff) * 100,
> ((ia_freq >> 8) & 0xff) * 100);
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> index 4168b9fc59e1..152b5493a455 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> @@ -35,7 +35,6 @@
> #define DEFAULT_LR_CONTEXT_RENDER_SIZE (22 * PAGE_SIZE)
> #define GEN8_LR_CONTEXT_RENDER_SIZE (20 * PAGE_SIZE)
> #define GEN9_LR_CONTEXT_RENDER_SIZE (22 * PAGE_SIZE)
> -#define GE
Re: [PATCH v1 1/5] dt-bindings: arm: mediatek: mmsys: add mt8195 SoC binding
Hi Jason,
Missatge de Jason-JH Lin del dia dl., 26
de jul. 2021 a les 9:02:
>
> On Fri, 2021-07-23 at 13:13 +0200, Enric Balletbo Serra wrote:
> > Hi Jason,
> >
> > Thank you for your patch.
> >
> > Missatge de jason-jh.lin del dia dj., 22
> > de jul. 2021 a les 11:26:
> > >
> > > There are 2 display hardware path in mt8195, namely vdosys0 and
> > > vdosys1, so add their definition in mtk-mmsys documentation.
> > >
> >
> > Just having 2 display hardware paths is not a reason to have two
> > compatibles, isn't the IP block the same? Why do you need to
> > introduce
> > the two compatibles?
> >
> > Thanks,
> > Enric
> >
>
> Hi Enric,
>
> Thanks for reviewing my patch.
>
> The reason for using two compatibles is that vdosys0 and vdosys1 are
> different IP blocks.
>
With that there are different IP blocks, what do you mean? Do you mean
that there are two completely different blocks with completely
different functionalities?
Or that there is the same IP block twice? I mean, of course, the
registers are different but has exactly the same functionality.
> Because mmsys provides clock control, other display function blocks may
> use them as clock provider.
>
> E.g.
> 1. mmsys with compatible="mediatek,mt8195-vdosys0"
> [v4,1/6] arm64: dts: mt8195: add display node for vdosys0
>
> https://patchwork.kernel.org/project/linux-mediatek/patch/20210723090233.24007-2-jason-jh@mediatek.com/
>
> ovl0: disp_ovl@1c00 {
> ...
> clocks = <&vdosys0 CLK_VDO0_DISP_OVL0>;
> ...
> };
>
> 2. mmsys with compatible="mediatek,mt8195-vdosys1"
> [v2,06/14] arm64: dts: mt8195: add display node for vdosys1
>
> https://patchwork.kernel.org/project/linux-mediatek/patch/20210722094551.15255-7-nancy@mediatek.com/
>
> vdo1_rdma0: vdo1_rdma@1c104000 {
> ...
> clocks = <&vdosys1 CLK_VDO1_MDP_RDMA0>;
> ...
> };
>
Note that I am talking without knowing the hardware in detail, but I
am wondering why I can't have something like this, where every mmsys
is a clock and reset controller provider.
vdosys0: syscon@1400 {
compatible = "mediatek,mt8195-mmsys", "syscon";
reg = <0 0x1400 0 0x1000>;
#clock-cells = <1>;
#reset-cells = <1>;
};
vdosys1: syscon@1500 {
compatible = "mediatek,mt8195-mmsys", "syscon";
reg = <0 0x1500 0 0x1000>;
#clock-cells = <1>;
#reset-cells = <1>;
};
ovl0: disp_ovl@1c00 {
...
clocks = <&vdosys0 CLK_VDO0_DISP_OVL0>;
...
};
vdo1_rdma0: vdo1_rdma@1c104000 {
...
clocks = <&vdosys1 CLK_VDO1_MDP_RDMA0>;
...
};
What are the differences between vdosys0 and vdosys1 from a hardware
point of view?
Cheers,
Enric
> Regards,
> Jason-JH.Lin
>
> > > Signed-off-by: jason-jh.lin
> > > ---
> > > this patch is base on [1][2]
> > >
> > > [1] dt-bindings: arm: mediatek: mmsys: convert to YAML format
> > > -
> > > https://urldefense.com/v3/__https://patchwork.kernel.org/project/linux-mediatek/patch/20210519161847.3747352-1-fpar...@baylibre.com/__;!!CTRNKA9wMg0ARbw!ycgPEK4yBDojiiZJC2E9mGwvxJbaLqhyUxzJIq0ckEP-JVteBcjFdc6ixkNbmknH8f2P$
> > >
> > > [2] dt-bindings: arm: mediatek: mmsys: add MT8365 SoC binding
> > > -
> > > https://urldefense.com/v3/__https://patchwork.kernel.org/project/linux-mediatek/patch/20210519161847.3747352-2-fpar...@baylibre.com/__;!!CTRNKA9wMg0ARbw!ycgPEK4yBDojiiZJC2E9mGwvxJbaLqhyUxzJIq0ckEP-JVteBcjFdc6ixkNbmju2GBrD$
> > >
> > > ---
> > > .../devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml|
> > > 2 ++
> > > 1 file changed, 2 insertions(+)
> > >
> > > diff --git
> > > a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yam
> > > l
> > > b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yam
> > > l
> > > index 2d4ff0ce387b..0789a9614f12 100644
> > > ---
> > > a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yam
> > > l
> > > +++
> > > b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yam
> > > l
> > > @@ -30,6 +30,8 @@ properties:
> > >- mediatek,mt8173-mmsys
> > >- mediatek,mt8183-mmsys
> > >- mediatek,mt8365-mmsys
> > > + - mediatek,mt8195-vdosys0
> > > + - mediatek,mt8195-vdosys1
> > >- const: syscon
> > >- items:
> > >- const: mediatek,mt7623-mmsys
> > > --
> > > 2.18.0
> > >
> --
Re: [PATCH 29/30] drm/i915: replace random CNL comments
On Fri, Jul 23, 2021 at 05:11:13PM -0700, Lucas De Marchi wrote:
> Cleanup remaining cases that we find CNL in the codebase.
>
> Signed-off-by: Lucas De Marchi
Reviewed-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/display/intel_bios.c | 2 +-
> drivers/gpu/drm/i915/display/intel_display.c | 2 +-
> drivers/gpu/drm/i915/display/intel_dp_aux.c | 1 -
> drivers/gpu/drm/i915/display/intel_dpll_mgr.h | 1 -
> drivers/gpu/drm/i915/display/intel_vbt_defs.h | 2 +-
> drivers/gpu/drm/i915/intel_device_info.h | 2 +-
> 6 files changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
> b/drivers/gpu/drm/i915/display/intel_bios.c
> index 4172c8ee6aa6..e86e6ed2d3bf 100644
> --- a/drivers/gpu/drm/i915/display/intel_bios.c
> +++ b/drivers/gpu/drm/i915/display/intel_bios.c
> @@ -1998,7 +1998,7 @@ static void parse_ddi_port(struct drm_i915_private
> *i915,
> "Port %c VBT HDMI boost level: %d\n",
> port_name(port), hdmi_boost_level);
>
> - /* DP max link rate for CNL+ */
> + /* DP max link rate for GLK+ */
> if (i915->vbt.version >= 216) {
> if (i915->vbt.version >= 230)
> info->dp_max_link_rate =
> parse_bdb_230_dp_max_link_rate(child->dp_max_link_rate);
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index ee6d5f8de24b..b49bf380baab 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -9778,7 +9778,7 @@ static int intel_atomic_check_async(struct
> intel_atomic_state *state)
>
> /*
>* FIXME: This check is kept generic for all platforms.
> - * Need to verify this for all gen9 and gen10 platforms to
> enable
> + * Need to verify this for all gen9 platforms to enable
>* this selectively if required.
>*/
> switch (new_plane_state->hw.fb->modifier) {
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux.c
> b/drivers/gpu/drm/i915/display/intel_dp_aux.c
> index 7c048d2ecf43..f483f479dd0b 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_aux.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_aux.c
> @@ -158,7 +158,6 @@ static u32 skl_get_aux_send_ctl(struct intel_dp *intel_dp,
> /*
>* Max timeout values:
>* SKL-GLK: 1.6ms
> - * CNL: 3.2ms
>* ICL+: 4ms
>*/
> ret = DP_AUX_CH_CTL_SEND_BUSY |
> diff --git a/drivers/gpu/drm/i915/display/intel_dpll_mgr.h
> b/drivers/gpu/drm/i915/display/intel_dpll_mgr.h
> index 7fd031a70cfd..6b19f74efd61 100644
> --- a/drivers/gpu/drm/i915/display/intel_dpll_mgr.h
> +++ b/drivers/gpu/drm/i915/display/intel_dpll_mgr.h
> @@ -206,7 +206,6 @@ struct intel_dpll_hw_state {
>
> /* cnl */
> u32 cfgcr0;
> - /* CNL also uses cfgcr1 */
>
> /* bxt */
> u32 ebb0, ebb4, pll0, pll1, pll2, pll3, pll6, pll8, pll9, pll10,
> pcsdw12;
> diff --git a/drivers/gpu/drm/i915/display/intel_vbt_defs.h
> b/drivers/gpu/drm/i915/display/intel_vbt_defs.h
> index dbe24d7e7375..330077c2e588 100644
> --- a/drivers/gpu/drm/i915/display/intel_vbt_defs.h
> +++ b/drivers/gpu/drm/i915/display/intel_vbt_defs.h
> @@ -456,7 +456,7 @@ struct child_device_config {
> u16 dp_gpio_pin_num;/* 195 */
> u8 dp_iboost_level:4; /* 196 */
> u8 hdmi_iboost_level:4; /* 196 */
> - u8 dp_max_link_rate:3; /* 216/230 CNL+
> */
> + u8 dp_max_link_rate:3; /* 216/230 GLK+
> */
> u8 dp_max_link_rate_reserved:5; /* 216/230 */
> } __packed;
>
> diff --git a/drivers/gpu/drm/i915/intel_device_info.h
> b/drivers/gpu/drm/i915/intel_device_info.h
> index 057c9aa6f9c6..ef1eecd259e0 100644
> --- a/drivers/gpu/drm/i915/intel_device_info.h
> +++ b/drivers/gpu/drm/i915/intel_device_info.h
> @@ -103,7 +103,7 @@ enum intel_platform {
> #define INTEL_SUBPLATFORM_ULT(0)
> #define INTEL_SUBPLATFORM_ULX(1)
>
> -/* CNL/ICL */
> +/* ICL */
> #define INTEL_SUBPLATFORM_PORTF (0)
>
> /* DG2 */
> --
> 2.31.1
>
Re: [PATCH 17/30] drm/i915/display: rename CNL references in skl_scaler.c
On Fri, Jul 23, 2021 at 05:11:01PM -0700, Lucas De Marchi wrote:
> With the removal of CNL, let's consider GLK as the first platform using
> those constants since GLK has DISPLAY_VER == 10.
>
> Signed-off-by: Lucas De Marchi
Reviewed-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/display/skl_scaler.c | 10 +-
> drivers/gpu/drm/i915/i915_reg.h | 4 ++--
> 2 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/skl_scaler.c
> b/drivers/gpu/drm/i915/display/skl_scaler.c
> index 911a113ee006..ebdd3115de16 100644
> --- a/drivers/gpu/drm/i915/display/skl_scaler.c
> +++ b/drivers/gpu/drm/i915/display/skl_scaler.c
> @@ -341,12 +341,12 @@ static u16 cnl_nearest_filter_coef(int t)
> *
> */
>
> -static void cnl_program_nearest_filter_coefs(struct drm_i915_private
> *dev_priv,
> +static void glk_program_nearest_filter_coefs(struct drm_i915_private
> *dev_priv,
>enum pipe pipe, int id, int set)
> {
> int i;
>
> - intel_de_write_fw(dev_priv, CNL_PS_COEF_INDEX_SET(pipe, id, set),
> + intel_de_write_fw(dev_priv, GLK_PS_COEF_INDEX_SET(pipe, id, set),
> PS_COEE_INDEX_AUTO_INC);
>
> for (i = 0; i < 17 * 7; i += 2) {
> @@ -359,11 +359,11 @@ static void cnl_program_nearest_filter_coefs(struct
> drm_i915_private *dev_priv,
> t = cnl_coef_tap(i + 1);
> tmp |= cnl_nearest_filter_coef(t) << 16;
>
> - intel_de_write_fw(dev_priv, CNL_PS_COEF_DATA_SET(pipe, id, set),
> + intel_de_write_fw(dev_priv, GLK_PS_COEF_DATA_SET(pipe, id, set),
> tmp);
> }
>
> - intel_de_write_fw(dev_priv, CNL_PS_COEF_INDEX_SET(pipe, id, set), 0);
> + intel_de_write_fw(dev_priv, GLK_PS_COEF_INDEX_SET(pipe, id, set), 0);
> }
>
> static u32 skl_scaler_get_filter_select(enum drm_scaling_filter filter, int
> set)
> @@ -386,7 +386,7 @@ static void skl_scaler_setup_filter(struct
> drm_i915_private *dev_priv, enum pipe
> case DRM_SCALING_FILTER_DEFAULT:
> break;
> case DRM_SCALING_FILTER_NEAREST_NEIGHBOR:
> - cnl_program_nearest_filter_coefs(dev_priv, pipe, id, set);
> + glk_program_nearest_filter_coefs(dev_priv, pipe, id, set);
> break;
> default:
> MISSING_CASE(filter);
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 91e93f3e9649..d198b1a2d4b5 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -7726,11 +7726,11 @@ enum {
> #define SKL_PS_ECC_STAT(pipe, id) _MMIO_PIPE(pipe, \
> _ID(id, _PS_ECC_STAT_1A, _PS_ECC_STAT_2A), \
> _ID(id, _PS_ECC_STAT_1B, _PS_ECC_STAT_2B))
> -#define CNL_PS_COEF_INDEX_SET(pipe, id, set) _MMIO_PIPE(pipe,\
> +#define GLK_PS_COEF_INDEX_SET(pipe, id, set) _MMIO_PIPE(pipe,\
> _ID(id, _PS_COEF_SET0_INDEX_1A, _PS_COEF_SET0_INDEX_2A)
> + (set) * 8, \
> _ID(id, _PS_COEF_SET0_INDEX_1B, _PS_COEF_SET0_INDEX_2B)
> + (set) * 8)
>
> -#define CNL_PS_COEF_DATA_SET(pipe, id, set) _MMIO_PIPE(pipe, \
> +#define GLK_PS_COEF_DATA_SET(pipe, id, set) _MMIO_PIPE(pipe, \
> _ID(id, _PS_COEF_SET0_DATA_1A, _PS_COEF_SET0_DATA_2A) +
> (set) * 8, \
> _ID(id, _PS_COEF_SET0_DATA_1B, _PS_COEF_SET0_DATA_2B) +
> (set) * 8)
> /* legacy palette */
> --
> 2.31.1
>
Re: [Intel-gfx] [PATCH 30/30] drm/i915: switch num_scalers/num_sprites to consider DISPLAY_VER
On Fri, Jul 23, 2021 at 05:11:14PM -0700, Lucas De Marchi wrote:
> The numbers of scalers and sprites depend on the display version, so use
> it instead of GRAPHICS_VER. We were mixing both, which let me confused
> while removing CNL and GRAPHICS_VER == 10.
>
> Signed-off-by: Lucas De Marchi
> ---
> drivers/gpu/drm/i915/intel_device_info.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_device_info.c
> b/drivers/gpu/drm/i915/intel_device_info.c
> index ffe3b5d89a63..7023d36a9a28 100644
> --- a/drivers/gpu/drm/i915/intel_device_info.c
> +++ b/drivers/gpu/drm/i915/intel_device_info.c
> @@ -265,10 +265,10 @@ void intel_device_info_runtime_init(struct
> drm_i915_private *dev_priv)
> if (IS_ADLS_DISPLAY_STEP(dev_priv, STEP_A0, STEP_A2))
> for_each_pipe(dev_priv, pipe)
> runtime->num_scalers[pipe] = 0;
> - else if (GRAPHICS_VER(dev_priv) >= 11) {
> + else if (DISPLAY_VER(dev_priv) >= 11) {
> for_each_pipe(dev_priv, pipe)
> runtime->num_scalers[pipe] = 2;
> - } else if (GRAPHICS_VER(dev_priv) == 9) {
> + } else if (DISPLAY_VER(dev_priv) == 9) {
> runtime->num_scalers[PIPE_A] = 2;
> runtime->num_scalers[PIPE_B] = 2;
> runtime->num_scalers[PIPE_C] = 1;
> @@ -279,7 +279,7 @@ void intel_device_info_runtime_init(struct
> drm_i915_private *dev_priv)
> if (DISPLAY_VER(dev_priv) >= 13 || HAS_D12_PLANE_MINIMIZATION(dev_priv))
> for_each_pipe(dev_priv, pipe)
> runtime->num_sprites[pipe] = 4;
> - else if (GRAPHICS_VER(dev_priv) >= 11)
> + else if (DISPLAY_VER(dev_priv) >= 11)
> for_each_pipe(dev_priv, pipe)
> runtime->num_sprites[pipe] = 6;
> else if (IS_GEMINILAKE(dev_priv))
while at it we could probably change this to DISPLAY_VER == 10?!
but anyway:
Reviewed-by: Rodrigo Vivi
> @@ -301,7 +301,7 @@ void intel_device_info_runtime_init(struct
> drm_i915_private *dev_priv)
> } else if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
> for_each_pipe(dev_priv, pipe)
> runtime->num_sprites[pipe] = 2;
> - } else if (GRAPHICS_VER(dev_priv) >= 5 || IS_G4X(dev_priv)) {
> + } else if (DISPLAY_VER(dev_priv) >= 5 || IS_G4X(dev_priv)) {
> for_each_pipe(dev_priv, pipe)
> runtime->num_sprites[pipe] = 1;
> }
> --
> 2.31.1
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 21/30] drm/i915: remove explicit CNL handling from intel_pch.c
On Fri, Jul 23, 2021 at 05:11:05PM -0700, Lucas De Marchi wrote: > Remove references for CNL from pch detection. for a moment I almost thought you were removing the CNP support... > > Signed-off-by: Lucas De Marchi Reviewed-by: Rodrigo Vivi > --- > drivers/gpu/drm/i915/intel_pch.c | 5 + > 1 file changed, 1 insertion(+), 4 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_pch.c > b/drivers/gpu/drm/i915/intel_pch.c > index cc44164e242b..d1d4b97b86f5 100644 > --- a/drivers/gpu/drm/i915/intel_pch.c > +++ b/drivers/gpu/drm/i915/intel_pch.c > @@ -81,7 +81,6 @@ intel_pch_type(const struct drm_i915_private *dev_priv, > unsigned short id) > case INTEL_PCH_CNP_DEVICE_ID_TYPE: > drm_dbg_kms(&dev_priv->drm, "Found Cannon Lake PCH (CNP)\n"); > drm_WARN_ON(&dev_priv->drm, > - !IS_CANNONLAKE(dev_priv) && > !IS_COFFEELAKE(dev_priv) && > !IS_COMETLAKE(dev_priv)); > return PCH_CNP; > @@ -89,7 +88,6 @@ intel_pch_type(const struct drm_i915_private *dev_priv, > unsigned short id) > drm_dbg_kms(&dev_priv->drm, > "Found Cannon Lake LP PCH (CNP-LP)\n"); > drm_WARN_ON(&dev_priv->drm, > - !IS_CANNONLAKE(dev_priv) && > !IS_COFFEELAKE(dev_priv) && > !IS_COMETLAKE(dev_priv)); > return PCH_CNP; > @@ -171,8 +169,7 @@ intel_virt_detect_pch(const struct drm_i915_private > *dev_priv, > id = INTEL_PCH_MCC_DEVICE_ID_TYPE; > else if (IS_ICELAKE(dev_priv)) > id = INTEL_PCH_ICP_DEVICE_ID_TYPE; > - else if (IS_CANNONLAKE(dev_priv) || > - IS_COFFEELAKE(dev_priv) || > + else if (IS_COFFEELAKE(dev_priv) || >IS_COMETLAKE(dev_priv)) > id = INTEL_PCH_CNP_DEVICE_ID_TYPE; > else if (IS_KABYLAKE(dev_priv) || IS_SKYLAKE(dev_priv)) > -- > 2.31.1 > > ___ > Intel-gfx mailing list > intel-...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 02/30] drm/i915/display: split DISPLAY_VER 9 and 10 in intel_setup_outputs()
On Sat, Jul 24, 2021 at 10:02:15PM -0700, Lucas De Marchi wrote: > On Sat, Jul 24, 2021 at 06:41:21PM +0100, Christoph Hellwig wrote: > > Still tests fine: > > > > Tested-by: Christoph Hellwig > > I just pushed this to drm-intel-next as part of another series and > added your Tested-by. > > Rodrigo, can you pick this up for -fixes? This should go with your other > patch to fix the port mask, too. done. But while doing this and reviewing this series at the same time I got myself wondering if we shouldn't remove the PORT_F support entirely... > > Thanks for the bug report and test. > > Lucas De Marchi > ___ > Intel-gfx mailing list > intel-...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 26/30] drm/i915: finish removal of CNL
On Fri, Jul 23, 2021 at 05:11:10PM -0700, Lucas De Marchi wrote:
> With all the users removed, finish removing the CNL platform definitions.
> We will leave the PCI IDs around as those are exposed to userspace.
> Even if mesa doesn't support CNL anymore, let's avoid build breakages
> due to changing the headers.
>
> Signed-off-by: Lucas De Marchi
Reviewed-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/i915_drv.h | 7 +--
> drivers/gpu/drm/i915/i915_pci.c | 23 +--
> drivers/gpu/drm/i915/i915_perf.c | 1 -
> drivers/gpu/drm/i915/intel_device_info.c | 2 --
> drivers/gpu/drm/i915/intel_device_info.h | 2 --
> 5 files changed, 6 insertions(+), 29 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index dd2d196050d4..e3c8283d770c 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1437,7 +1437,6 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
> #define IS_GEMINILAKE(dev_priv) IS_PLATFORM(dev_priv, INTEL_GEMINILAKE)
> #define IS_COFFEELAKE(dev_priv) IS_PLATFORM(dev_priv, INTEL_COFFEELAKE)
> #define IS_COMETLAKE(dev_priv) IS_PLATFORM(dev_priv, INTEL_COMETLAKE)
> -#define IS_CANNONLAKE(dev_priv) IS_PLATFORM(dev_priv, INTEL_CANNONLAKE)
> #define IS_ICELAKE(dev_priv) IS_PLATFORM(dev_priv, INTEL_ICELAKE)
> #define IS_JSL_EHL(dev_priv) (IS_PLATFORM(dev_priv, INTEL_JASPERLAKE) || \
> IS_PLATFORM(dev_priv, INTEL_ELKHARTLAKE))
> @@ -1503,8 +1502,6 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
> #define IS_CML_GT2(dev_priv) (IS_COMETLAKE(dev_priv) && \
>INTEL_INFO(dev_priv)->gt == 2)
>
> -#define IS_CNL_WITH_PORT_F(dev_priv) \
> - IS_SUBPLATFORM(dev_priv, INTEL_CANNONLAKE, INTEL_SUBPLATFORM_PORTF)
> #define IS_ICL_WITH_PORT_F(dev_priv) \
> IS_SUBPLATFORM(dev_priv, INTEL_ICELAKE, INTEL_SUBPLATFORM_PORTF)
>
> @@ -1649,9 +1646,7 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
>
> /* WaRsDisableCoarsePowerGating:skl,cnl */
> #define NEEDS_WaRsDisableCoarsePowerGating(dev_priv) \
> - (IS_CANNONLAKE(dev_priv) || \
> - IS_SKL_GT3(dev_priv) ||\
> - IS_SKL_GT4(dev_priv))
> + (IS_SKL_GT3(dev_priv) || IS_SKL_GT4(dev_priv))
>
> #define HAS_GMBUS_IRQ(dev_priv) (GRAPHICS_VER(dev_priv) >= 4)
> #define HAS_GMBUS_BURST_READ(dev_priv) (GRAPHICS_VER(dev_priv) >= 10 || \
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index 48ea23dd3b5b..aea2c2d82fbf 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -787,27 +787,13 @@ static const struct intel_device_info cml_gt2_info = {
> .gt = 2,
> };
>
> -#define GEN10_FEATURES \
> - GEN9_FEATURES, \
> - GEN(10), \
> - .dbuf.size = 1024 - 4, /* 4 blocks for bypass path allocation */ \
> - .display.has_dsc = 1, \
> - .has_coherent_ggtt = false, \
> - GLK_COLORS
> -
> -static const struct intel_device_info cnl_info = {
> - GEN10_FEATURES,
> - PLATFORM(INTEL_CANNONLAKE),
> - .gt = 2,
> -};
> -
> #define GEN11_DEFAULT_PAGE_SIZES \
> .page_sizes = I915_GTT_PAGE_SIZE_4K | \
> I915_GTT_PAGE_SIZE_64K | \
> I915_GTT_PAGE_SIZE_2M
>
> #define GEN11_FEATURES \
> - GEN10_FEATURES, \
> + GEN9_FEATURES, \
> GEN11_DEFAULT_PAGE_SIZES, \
> .abox_mask = BIT(0), \
> .cpu_transcoder_mask = BIT(TRANSCODER_A) | BIT(TRANSCODER_B) | \
> @@ -830,10 +816,12 @@ static const struct intel_device_info cnl_info = {
> [TRANSCODER_DSI_1] = TRANSCODER_DSI1_OFFSET, \
> }, \
> GEN(11), \
> + .color = { .degamma_lut_size = 33, .gamma_lut_size = 262145 }, \
> .dbuf.size = 2048, \
> .dbuf.slice_mask = BIT(DBUF_S1) | BIT(DBUF_S2), \
> - .has_logical_ring_elsq = 1, \
> - .color = { .degamma_lut_size = 33, .gamma_lut_size = 262145 }
> + .display.has_dsc = 1, \
> + .has_coherent_ggtt = false, \
> + .has_logical_ring_elsq = 1
>
> static const struct intel_device_info icl_info = {
> GEN11_FEATURES,
> @@ -1123,7 +,6 @@ static const struct pci_device_id pciidlist[] = {
> INTEL_CML_GT2_IDS(&cml_gt2_info),
> INTEL_CML_U_GT1_IDS(&cml_gt1_info),
> INTEL_CML_U_GT2_IDS(&cml_gt2_info),
> - INTEL_CNL_IDS(&cnl_info),
> INTEL_ICL_11_IDS(&icl_info),
> INTEL_EHL_IDS(&ehl_info),
> INTEL_JSL_IDS(&jsl_info),
> diff --git a/drivers/gpu/drm/i915/i915_perf.c
> b/drivers/gpu/drm/i915/i915_perf.c
> index 838cc14c2f24..108774d651d9 100644
> --- a/drivers/gpu/drm/i915/i915_perf.c
> +++ b/drivers/gpu/drm/i915/i915_perf.c
> @@ -4319,7 +4319,6 @@ static void oa_init_supported_formats(struct i915_perf
> *perf)
> case INTEL_GEMINILAKE:
> case INTEL_COFFEELAKE:
> ca
Re: [PATCH 20/30] drm/i915: remove explicit CNL handling from intel_mocs.c
On Fri, Jul 23, 2021 at 05:11:04PM -0700, Lucas De Marchi wrote:
> Only one reference to CNL that is not needed, but code is the same for
> GEN9_BC, so leave the code around and just remove the special
> case for CNL.
>
> Signed-off-by: Lucas De Marchi
Reviewed-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/gt/intel_mocs.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_mocs.c
> b/drivers/gpu/drm/i915/gt/intel_mocs.c
> index 17848807f111..582c4423b95d 100644
> --- a/drivers/gpu/drm/i915/gt/intel_mocs.c
> +++ b/drivers/gpu/drm/i915/gt/intel_mocs.c
> @@ -352,7 +352,7 @@ static unsigned int get_mocs_settings(const struct
> drm_i915_private *i915,
> table->size = ARRAY_SIZE(icl_mocs_table);
> table->table = icl_mocs_table;
> table->n_entries = GEN9_NUM_MOCS_ENTRIES;
> - } else if (IS_GEN9_BC(i915) || IS_CANNONLAKE(i915)) {
> + } else if (IS_GEN9_BC(i915)) {
> table->size = ARRAY_SIZE(skl_mocs_table);
> table->n_entries = GEN9_NUM_MOCS_ENTRIES;
> table->table = skl_mocs_table;
> --
> 2.31.1
>
Re: [Intel-gfx] [PATCH 14/30] drm/i915/display: remove explicit CNL handling from skl_universal_plane.c
On Fri, Jul 23, 2021 at 05:10:58PM -0700, Lucas De Marchi wrote:
> The only real platform with DISPLAY_VER == 10 is GLK. We don't need to
> handle CNL explicitly in skl_universal_plane.c.
>
> Remove code and rename functions/macros accordingly to use ICL prefix.
>
> Signed-off-by: Lucas De Marchi
Reviewed-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/display/skl_universal_plane.c | 14 +++---
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c
> b/drivers/gpu/drm/i915/display/skl_universal_plane.c
> index 3ad04bf2a0fd..0f40f8b07724 100644
> --- a/drivers/gpu/drm/i915/display/skl_universal_plane.c
> +++ b/drivers/gpu/drm/i915/display/skl_universal_plane.c
> @@ -835,7 +835,7 @@ static u32 skl_plane_ctl_rotate(unsigned int rotate)
> return 0;
> }
>
> -static u32 cnl_plane_ctl_flip(unsigned int reflect)
> +static u32 icl_plane_ctl_flip(unsigned int reflect)
> {
> switch (reflect) {
> case 0:
> @@ -917,8 +917,8 @@ static u32 skl_plane_ctl(const struct intel_crtc_state
> *crtc_state,
> plane_ctl |= skl_plane_ctl_tiling(fb->modifier);
> plane_ctl |= skl_plane_ctl_rotate(rotation & DRM_MODE_ROTATE_MASK);
>
> - if (DISPLAY_VER(dev_priv) >= 11 || IS_CANNONLAKE(dev_priv))
> - plane_ctl |= cnl_plane_ctl_flip(rotation &
> + if (DISPLAY_VER(dev_priv) >= 11)
> + plane_ctl |= icl_plane_ctl_flip(rotation &
> DRM_MODE_REFLECT_MASK);
>
> if (key->flags & I915_SET_COLORKEY_DESTINATION)
> @@ -1828,7 +1828,7 @@ static bool skl_plane_has_ccs(struct drm_i915_private
> *dev_priv,
> if (plane_id == PLANE_CURSOR)
> return false;
>
> - if (DISPLAY_VER(dev_priv) >= 11 || IS_CANNONLAKE(dev_priv))
> + if (DISPLAY_VER(dev_priv) >= 11)
> return true;
>
> if (IS_GEMINILAKE(dev_priv))
> @@ -2144,7 +2144,7 @@ skl_universal_plane_create(struct drm_i915_private
> *dev_priv,
> DRM_MODE_ROTATE_0 | DRM_MODE_ROTATE_90 |
> DRM_MODE_ROTATE_180 | DRM_MODE_ROTATE_270;
>
> - if (DISPLAY_VER(dev_priv) >= 11 || IS_CANNONLAKE(dev_priv))
> + if (DISPLAY_VER(dev_priv) >= 11)
> supported_rotations |= DRM_MODE_REFLECT_X;
>
> drm_plane_create_rotation_property(&plane->base,
> @@ -2174,7 +2174,7 @@ skl_universal_plane_create(struct drm_i915_private
> *dev_priv,
> if (DISPLAY_VER(dev_priv) >= 12)
> drm_plane_enable_fb_damage_clips(&plane->base);
>
> - if (DISPLAY_VER(dev_priv) >= 11 || IS_CANNONLAKE(dev_priv))
> + if (DISPLAY_VER(dev_priv) >= 11)
> drm_plane_create_scaling_filter_property(&plane->base,
> BIT(DRM_SCALING_FILTER_DEFAULT)
> |
>
> BIT(DRM_SCALING_FILTER_NEAREST_NEIGHBOR));
> @@ -2295,7 +2295,7 @@ skl_get_initial_plane_config(struct intel_crtc *crtc,
> break;
> }
>
> - if ((DISPLAY_VER(dev_priv) >= 11 || IS_CANNONLAKE(dev_priv)) && val &
> PLANE_CTL_FLIP_HORIZONTAL)
> + if (DISPLAY_VER(dev_priv) >= 11 && val & PLANE_CTL_FLIP_HORIZONTAL)
> plane_config->rotation |= DRM_MODE_REFLECT_X;
>
> /* 90/270 degree rotation would require extra work */
> --
> 2.31.1
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [PATCH 24/30] drm/i915: rename CNL references in intel_dram.c
On Fri, Jul 23, 2021 at 05:11:08PM -0700, Lucas De Marchi wrote:
> With the removal of CNL, let's consider ICL as the first platform using
> those constants.
>
> Signed-off-by: Lucas De Marchi
Reviewed-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/i915_reg.h | 24 +++
> drivers/gpu/drm/i915/intel_dram.c | 32 +++
> 2 files changed, 28 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index f032a4c8b26d..8782d1723254 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -11082,18 +11082,18 @@ enum skl_power_gate {
> #define SKL_DRAM_RANK_1 (0x0 << 10)
> #define SKL_DRAM_RANK_2 (0x1 << 10)
> #define SKL_DRAM_RANK_MASK (0x1 << 10)
> -#define CNL_DRAM_SIZE_MASK 0x7F
> -#define CNL_DRAM_WIDTH_MASK (0x3 << 7)
> -#define CNL_DRAM_WIDTH_SHIFT7
> -#define CNL_DRAM_WIDTH_X8 (0x0 << 7)
> -#define CNL_DRAM_WIDTH_X16 (0x1 << 7)
> -#define CNL_DRAM_WIDTH_X32 (0x2 << 7)
> -#define CNL_DRAM_RANK_MASK (0x3 << 9)
> -#define CNL_DRAM_RANK_SHIFT 9
> -#define CNL_DRAM_RANK_1 (0x0 << 9)
> -#define CNL_DRAM_RANK_2 (0x1 << 9)
> -#define CNL_DRAM_RANK_3 (0x2 << 9)
> -#define CNL_DRAM_RANK_4 (0x3 << 9)
> +#define ICL_DRAM_SIZE_MASK 0x7F
> +#define ICL_DRAM_WIDTH_MASK (0x3 << 7)
> +#define ICL_DRAM_WIDTH_SHIFT7
> +#define ICL_DRAM_WIDTH_X8 (0x0 << 7)
> +#define ICL_DRAM_WIDTH_X16 (0x1 << 7)
> +#define ICL_DRAM_WIDTH_X32 (0x2 << 7)
> +#define ICL_DRAM_RANK_MASK (0x3 << 9)
> +#define ICL_DRAM_RANK_SHIFT 9
> +#define ICL_DRAM_RANK_1 (0x0 << 9)
> +#define ICL_DRAM_RANK_2 (0x1 << 9)
> +#define ICL_DRAM_RANK_3 (0x2 << 9)
> +#define ICL_DRAM_RANK_4 (0x3 << 9)
>
> #define SA_PERF_STATUS_0_0_0_MCHBAR_PC
> _MMIO(MCHBAR_MIRROR_BASE_SNB + 0x5918)
> #define DG1_QCLK_RATIO_MASK REG_GENMASK(9, 2)
> diff --git a/drivers/gpu/drm/i915/intel_dram.c
> b/drivers/gpu/drm/i915/intel_dram.c
> index 9675bb94b70b..34d6cf440352 100644
> --- a/drivers/gpu/drm/i915/intel_dram.c
> +++ b/drivers/gpu/drm/i915/intel_dram.c
> @@ -77,21 +77,21 @@ static int skl_get_dimm_ranks(u16 val)
> }
>
> /* Returns total Gb for the whole DIMM */
> -static int cnl_get_dimm_size(u16 val)
> +static int icl_get_dimm_size(u16 val)
> {
> - return (val & CNL_DRAM_SIZE_MASK) * 8 / 2;
> + return (val & ICL_DRAM_SIZE_MASK) * 8 / 2;
> }
>
> -static int cnl_get_dimm_width(u16 val)
> +static int icl_get_dimm_width(u16 val)
> {
> - if (cnl_get_dimm_size(val) == 0)
> + if (icl_get_dimm_size(val) == 0)
> return 0;
>
> - switch (val & CNL_DRAM_WIDTH_MASK) {
> - case CNL_DRAM_WIDTH_X8:
> - case CNL_DRAM_WIDTH_X16:
> - case CNL_DRAM_WIDTH_X32:
> - val = (val & CNL_DRAM_WIDTH_MASK) >> CNL_DRAM_WIDTH_SHIFT;
> + switch (val & ICL_DRAM_WIDTH_MASK) {
> + case ICL_DRAM_WIDTH_X8:
> + case ICL_DRAM_WIDTH_X16:
> + case ICL_DRAM_WIDTH_X32:
> + val = (val & ICL_DRAM_WIDTH_MASK) >> ICL_DRAM_WIDTH_SHIFT;
> return 8 << val;
> default:
> MISSING_CASE(val);
> @@ -99,12 +99,12 @@ static int cnl_get_dimm_width(u16 val)
> }
> }
>
> -static int cnl_get_dimm_ranks(u16 val)
> +static int icl_get_dimm_ranks(u16 val)
> {
> - if (cnl_get_dimm_size(val) == 0)
> + if (icl_get_dimm_size(val) == 0)
> return 0;
>
> - val = (val & CNL_DRAM_RANK_MASK) >> CNL_DRAM_RANK_SHIFT;
> + val = (val & ICL_DRAM_RANK_MASK) >> ICL_DRAM_RANK_SHIFT;
>
> return val + 1;
> }
> @@ -121,10 +121,10 @@ skl_dram_get_dimm_info(struct drm_i915_private *i915,
> struct dram_dimm_info *dimm,
> int channel, char dimm_name, u16 val)
> {
> - if (GRAPHICS_VER(i915) >= 10) {
> - dimm->size = cnl_get_dimm_size(val);
> - dimm->width = cnl_get_dimm_width(val);
> - dimm->ranks = cnl_get_dimm_ranks(val);
> + if (GRAPHICS_VER(i915) >= 11) {
> + dimm->size = icl_get_dimm_size(val);
> + dimm->width = icl_get_dimm_width(val);
> + dimm->ranks = icl_get_dimm_ranks(val);
> } else {
> dimm->size = skl_get_dimm_size(val);
> dimm->width = skl_get_dimm_width(val);
> --
> 2.31.1
>
Re: [PATCH v4 5/7] drm/panfrost: Add a new ioctl to submit batches
On Thu, 8 Jul 2021 14:10:45 +0200 Christian König wrote: > >> --- a/drivers/gpu/drm/panfrost/panfrost_job.c > >> +++ b/drivers/gpu/drm/panfrost/panfrost_job.c > >> @@ -254,6 +254,9 @@ static int panfrost_acquire_object_fences(struct > >> panfrost_job *job) > >>return ret; > >>} > >> > >> + if (job->bo_flags[i] & PANFROST_BO_REF_NO_IMPLICIT_DEP) > >> + continue; > > This breaks dma_resv rules. I'll send out patch set fixing this pattern in > > other drivers, I'll ping you on that for what you need to change. Should > > go out today or so. I guess you're talking about [1]. TBH, I don't quite see the point of exposing a 'no-implicit' flag if we end up forcing this implicit dep anyway, but I'm probably missing something. > > I'm really wondering if the behavior that the exclusive fences replaces > all the shared fences was such a good idea. Is that what's done in [1], or are you talking about a different patchset/approach? > > It just allows drivers to mess up things in a way which can be easily > used to compromise the system. I must admit I'm a bit lost, so I'm tempted to drop that flag for now :-). [1]https://patchwork.freedesktop.org/patch/443711/?series=92334&rev=3
Re: [Intel-gfx] [PATCH 15/30] drm/i915/display: remove explicit CNL handling from intel_display_power.c
On Fri, Jul 23, 2021 at 05:10:59PM -0700, Lucas De Marchi wrote:
> The only real platform with DISPLAY_VER == 10 is GLK. We don't need to
> handle CNL explicitly in intel_display_power.c.
>
> Signed-off-by: Lucas De Marchi
Reviewed-by: Rodrigo Vivi
> ---
> .../drm/i915/display/intel_display_power.c| 289 --
> .../drm/i915/display/intel_display_power.h| 2 -
> drivers/gpu/drm/i915/i915_reg.h | 13 -
> 3 files changed, 304 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
> b/drivers/gpu/drm/i915/display/intel_display_power.c
> index 81efc77bada0..44aef0c44ab7 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_power.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_power.c
> @@ -447,17 +447,6 @@ static void hsw_power_well_enable(struct
> drm_i915_private *dev_priv,
>
> hsw_wait_for_power_well_enable(dev_priv, power_well, false);
>
> - /* Display WA #1178: cnl */
> - if (IS_CANNONLAKE(dev_priv) &&
> - pw_idx >= GLK_PW_CTL_IDX_AUX_B &&
> - pw_idx <= CNL_PW_CTL_IDX_AUX_F) {
> - u32 val;
> -
> - val = intel_de_read(dev_priv, CNL_AUX_ANAOVRD1(pw_idx));
> - val |= CNL_AUX_ANAOVRD1_ENABLE | CNL_AUX_ANAOVRD1_LDO_BYPASS;
> - intel_de_write(dev_priv, CNL_AUX_ANAOVRD1(pw_idx), val);
> - }
> -
> if (power_well->desc->hsw.has_fuses) {
> enum skl_power_gate pg;
>
> @@ -2743,63 +2732,6 @@ intel_display_power_put_mask_in_set(struct
> drm_i915_private *i915,
> BIT_ULL(POWER_DOMAIN_GMBUS) | \
> BIT_ULL(POWER_DOMAIN_INIT))
>
> -#define CNL_DISPLAY_POWERWELL_2_POWER_DOMAINS ( \
> - BIT_ULL(POWER_DOMAIN_TRANSCODER_A) |\
> - BIT_ULL(POWER_DOMAIN_PIPE_B) | \
> - BIT_ULL(POWER_DOMAIN_TRANSCODER_B) |\
> - BIT_ULL(POWER_DOMAIN_PIPE_C) | \
> - BIT_ULL(POWER_DOMAIN_TRANSCODER_C) |\
> - BIT_ULL(POWER_DOMAIN_PIPE_B_PANEL_FITTER) | \
> - BIT_ULL(POWER_DOMAIN_PIPE_C_PANEL_FITTER) | \
> - BIT_ULL(POWER_DOMAIN_PORT_DDI_B_LANES) |\
> - BIT_ULL(POWER_DOMAIN_PORT_DDI_C_LANES) |\
> - BIT_ULL(POWER_DOMAIN_PORT_DDI_D_LANES) |\
> - BIT_ULL(POWER_DOMAIN_PORT_DDI_F_LANES) |\
> - BIT_ULL(POWER_DOMAIN_AUX_B) | \
> - BIT_ULL(POWER_DOMAIN_AUX_C) | \
> - BIT_ULL(POWER_DOMAIN_AUX_D) | \
> - BIT_ULL(POWER_DOMAIN_AUX_F) | \
> - BIT_ULL(POWER_DOMAIN_AUDIO) | \
> - BIT_ULL(POWER_DOMAIN_VGA) | \
> - BIT_ULL(POWER_DOMAIN_INIT))
> -#define CNL_DISPLAY_DDI_A_IO_POWER_DOMAINS ( \
> - BIT_ULL(POWER_DOMAIN_PORT_DDI_A_IO) | \
> - BIT_ULL(POWER_DOMAIN_INIT))
> -#define CNL_DISPLAY_DDI_B_IO_POWER_DOMAINS ( \
> - BIT_ULL(POWER_DOMAIN_PORT_DDI_B_IO) | \
> - BIT_ULL(POWER_DOMAIN_INIT))
> -#define CNL_DISPLAY_DDI_C_IO_POWER_DOMAINS ( \
> - BIT_ULL(POWER_DOMAIN_PORT_DDI_C_IO) | \
> - BIT_ULL(POWER_DOMAIN_INIT))
> -#define CNL_DISPLAY_DDI_D_IO_POWER_DOMAINS ( \
> - BIT_ULL(POWER_DOMAIN_PORT_DDI_D_IO) | \
> - BIT_ULL(POWER_DOMAIN_INIT))
> -#define CNL_DISPLAY_AUX_A_POWER_DOMAINS (\
> - BIT_ULL(POWER_DOMAIN_AUX_A) | \
> - BIT_ULL(POWER_DOMAIN_AUX_IO_A) |\
> - BIT_ULL(POWER_DOMAIN_INIT))
> -#define CNL_DISPLAY_AUX_B_POWER_DOMAINS (\
> - BIT_ULL(POWER_DOMAIN_AUX_B) | \
> - BIT_ULL(POWER_DOMAIN_INIT))
> -#define CNL_DISPLAY_AUX_C_POWER_DOMAINS (\
> - BIT_ULL(POWER_DOMAIN_AUX_C) | \
> - BIT_ULL(POWER_DOMAIN_INIT))
> -#define CNL_DISPLAY_AUX_D_POWER_DOMAINS (\
> - BIT_ULL(POWER_DOMAIN_AUX_D) | \
> - BIT_ULL(POWER_DOMAIN_INIT))
> -#define CNL_DISPLAY_AUX_F_POWER_DOMAINS (\
> - BIT_ULL(POWER_DOMAIN_AUX_F) | \
> - BIT_ULL(POWER_DOMAIN_INIT))
> -#define CNL_DISPLAY_DDI_F_IO_POWER_DOMAINS ( \
> - BIT_ULL(POWER_DOMAIN_PORT_DDI_F_IO) | \
> - BIT_ULL(POWER_DOMAIN_INIT))
> -#define CNL_DISPLAY_DC_OFF_POWER_DOMAINS ( \
> - CNL_DISPLAY_POWERWELL_2_POWER_DOMAINS | \
> - BIT_ULL(POWER_DOMAIN_GT_IRQ) | \
> - BIT_ULL(POWER_DOMAIN_MODESET) | \
> - BIT_ULL(POWER_DOMAIN_AUX_A) | \
> - BIT_ULL(POWER_DOMAIN_INIT))
> -
> /*
> * ICL PW_0/PG_0 domains (HW/DMC control):
> * - PCI
> @@ -3706,148 +3638,6 @@ static const struct i915_power_well_desc
> glk_power_wells[] = {
> },
> };
>
> -static const struct i915_power_well_desc cnl_power_wells[] = {
> - {
> - .name = "alway
Aw: Re: Re: [PATCH] soc: mediatek: mmsys: fix HDMI output on mt7623/bananapi-r2
Hi > Gesendet: Montag, 26. Juli 2021 um 02:27 Uhr > Von: "Chun-Kuang Hu" > As I've discussed in [1], SOUT has many bits and need to be cleared > before set new value. Of course, write only could do the clear, but > for MOUT, it clear the bits that should not be cleared. If you want to > use the table, you need to implement the 'mask'. > > [1] > https://patchwork.kernel.org/project/linux-mediatek/patch/trinity-937ebfa3-d123-42de-a289-3ad0dbc09782-1625830110576@3c-app-gmx-bap43/ I've added the mask like you did here [1] on my repo [2] and it works too...should i use you as author as i only take your code when posting? regards Frank [1] https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/2345186/5/drivers/soc/mediatek/mtk-mmsys.c#294 [2] https://github.com/frank-w/BPI-R2-4.14/commits/5.14-mmsys
Re: [PATCH 12/30] drm/i915/display: remove explicit CNL handling from intel_dpll_mgr.c
On Fri, Jul 23, 2021 at 05:10:56PM -0700, Lucas De Marchi wrote:
> The only real platform with DISPLAY_VER == 10 is GLK. We don't need to
> handle CNL explicitly in intel_ddi.c.
>
> A lot of special code for CNL can be removed. There were some
> __cnl.*() functions that were created to share the implementation
> between ICL and CNL. Those are now embedded in the only caller, in ICL.
>
> Remove code and rename functions/macros accordingly to use ICL prefix
> for those that are still needed.
>
> Verified with:
>
> make EXTRA_CFLAGS=-Wunused drivers/gpu/drm/i915/display/intel_dpll_mgr.o
good idea...
>
> Signed-off-by: Lucas De Marchi
Reviewed-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 586 +++---
> drivers/gpu/drm/i915/i915_reg.h | 4 +-
> 2 files changed, 96 insertions(+), 494 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> index 8e2bd8fa090a..0d72917e5670 100644
> --- a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> +++ b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> @@ -168,7 +168,7 @@ intel_combo_pll_enable_reg(struct drm_i915_private *i915,
> else if (IS_JSL_EHL(i915) && (pll->info->id == DPLL_ID_EHL_DPLL4))
> return MG_PLL_ENABLE(0);
>
> - return CNL_DPLL_ENABLE(pll->info->id);
> + return ICL_DPLL_ENABLE(pll->info->id);
> }
>
> static i915_reg_t
> @@ -2346,160 +2346,7 @@ static const struct intel_dpll_mgr bxt_pll_mgr = {
> .dump_hw_state = bxt_dump_hw_state,
> };
>
> -static void cnl_ddi_pll_enable(struct drm_i915_private *dev_priv,
> -struct intel_shared_dpll *pll)
> -{
> - const enum intel_dpll_id id = pll->info->id;
> - u32 val;
> -
> - /* 1. Enable DPLL power in DPLL_ENABLE. */
> - val = intel_de_read(dev_priv, CNL_DPLL_ENABLE(id));
> - val |= PLL_POWER_ENABLE;
> - intel_de_write(dev_priv, CNL_DPLL_ENABLE(id), val);
> -
> - /* 2. Wait for DPLL power state enabled in DPLL_ENABLE. */
> - if (intel_de_wait_for_set(dev_priv, CNL_DPLL_ENABLE(id),
> - PLL_POWER_STATE, 5))
> - drm_err(&dev_priv->drm, "PLL %d Power not enabled\n", id);
> -
> - /*
> - * 3. Configure DPLL_CFGCR0 to set SSC enable/disable,
> - * select DP mode, and set DP link rate.
> - */
> - val = pll->state.hw_state.cfgcr0;
> - intel_de_write(dev_priv, CNL_DPLL_CFGCR0(id), val);
> -
> - /* 4. Reab back to ensure writes completed */
> - intel_de_posting_read(dev_priv, CNL_DPLL_CFGCR0(id));
> -
> - /* 3. Configure DPLL_CFGCR0 */
> - /* Avoid touch CFGCR1 if HDMI mode is not enabled */
> - if (pll->state.hw_state.cfgcr0 & DPLL_CFGCR0_HDMI_MODE) {
> - val = pll->state.hw_state.cfgcr1;
> - intel_de_write(dev_priv, CNL_DPLL_CFGCR1(id), val);
> - /* 4. Reab back to ensure writes completed */
> - intel_de_posting_read(dev_priv, CNL_DPLL_CFGCR1(id));
> - }
> -
> - /*
> - * 5. If the frequency will result in a change to the voltage
> - * requirement, follow the Display Voltage Frequency Switching
> - * Sequence Before Frequency Change
> - *
> - * Note: DVFS is actually handled via the cdclk code paths,
> - * hence we do nothing here.
> - */
> -
> - /* 6. Enable DPLL in DPLL_ENABLE. */
> - val = intel_de_read(dev_priv, CNL_DPLL_ENABLE(id));
> - val |= PLL_ENABLE;
> - intel_de_write(dev_priv, CNL_DPLL_ENABLE(id), val);
> -
> - /* 7. Wait for PLL lock status in DPLL_ENABLE. */
> - if (intel_de_wait_for_set(dev_priv, CNL_DPLL_ENABLE(id), PLL_LOCK, 5))
> - drm_err(&dev_priv->drm, "PLL %d not locked\n", id);
> -
> - /*
> - * 8. If the frequency will result in a change to the voltage
> - * requirement, follow the Display Voltage Frequency Switching
> - * Sequence After Frequency Change
> - *
> - * Note: DVFS is actually handled via the cdclk code paths,
> - * hence we do nothing here.
> - */
> -
> - /*
> - * 9. turn on the clock for the DDI and map the DPLL to the DDI
> - * Done at intel_ddi_clk_select
> - */
> -}
> -
> -static void cnl_ddi_pll_disable(struct drm_i915_private *dev_priv,
> - struct intel_shared_dpll *pll)
> -{
> - const enum intel_dpll_id id = pll->info->id;
> - u32 val;
> -
> - /*
> - * 1. Configure DPCLKA_CFGCR0 to turn off the clock for the DDI.
> - * Done at intel_ddi_post_disable
> - */
> -
> - /*
> - * 2. If the frequency will result in a change to the voltage
> - * requirement, follow the Display Voltage Frequency Switching
> - * Sequence Before Frequency Change
> - *
> - * Note: DVFS is actually handled via the cdclk code paths,
> - * hence we do nothing here.
> - */
> -
> - /* 3. Disable DPLL through DPLL_ENA
Re: [PATCH 25/30] drm/i915/gt: rename CNL references in intel_engine.h
On Fri, Jul 23, 2021 at 05:11:09PM -0700, Lucas De Marchi wrote:
> With the removal of CNL, let's consider ICL as the first platform using
> that index.
>
> Signed-off-by: Lucas De Marchi
Reviewed-by: Rodrigo Vivi
(
I got myself thinking that some patches like this could be squashed into others,
and a few of them made with coccinele, but in the end I like the approach you
took. It's been very easy to review this series...
)
> ---
> drivers/gpu/drm/i915/gt/intel_engine.h | 2 +-
> drivers/gpu/drm/i915/i915_drv.h| 4 ++--
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine.h
> b/drivers/gpu/drm/i915/gt/intel_engine.h
> index f911c1224ab2..dfb400766db5 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine.h
> +++ b/drivers/gpu/drm/i915/gt/intel_engine.h
> @@ -179,7 +179,7 @@ intel_write_status_page(struct intel_engine_cs *engine,
> int reg, u32 value)
>
> #define I915_HWS_CSB_BUF0_INDEX 0x10
> #define I915_HWS_CSB_WRITE_INDEX 0x1f
> -#define CNL_HWS_CSB_WRITE_INDEX 0x2f
> +#define ICL_HWS_CSB_WRITE_INDEX 0x2f
>
> void intel_engine_stop(struct intel_engine_cs *engine);
> void intel_engine_cleanup(struct intel_engine_cs *engine);
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index d118834a4ed9..dd2d196050d4 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1959,8 +1959,8 @@ int remap_io_sg(struct vm_area_struct *vma,
>
> static inline int intel_hws_csb_write_index(struct drm_i915_private *i915)
> {
> - if (GRAPHICS_VER(i915) >= 10)
> - return CNL_HWS_CSB_WRITE_INDEX;
> + if (GRAPHICS_VER(i915) >= 11)
> + return ICL_HWS_CSB_WRITE_INDEX;
> else
> return I915_HWS_CSB_WRITE_INDEX;
> }
> --
> 2.31.1
>
Re: [PATCH 11/30] drm/i915/display: remove explicit CNL handling from intel_dp.c
On Fri, Jul 23, 2021 at 05:10:55PM -0700, Lucas De Marchi wrote:
> The only real platform with DISPLAY_VER == 10 is GLK. We don't need to
> handle CNL explicitly in intel_dp.c.
>
> Remove code and rename functions/macros accordingly to use ICL prefix.
>
> Signed-off-by: Lucas De Marchi
Reviewed-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 35 -
> 1 file changed, 5 insertions(+), 30 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index c386ef8eb200..db701ec5a221 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -222,29 +222,6 @@ bool intel_dp_can_bigjoiner(struct intel_dp *intel_dp)
>encoder->port != PORT_A);
> }
>
> -static int cnl_max_source_rate(struct intel_dp *intel_dp)
> -{
> - struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> - struct drm_i915_private *dev_priv = to_i915(dig_port->base.base.dev);
> - enum port port = dig_port->base.port;
> -
> - u32 voltage = intel_de_read(dev_priv, CNL_PORT_COMP_DW3) &
> VOLTAGE_INFO_MASK;
> -
> - /* Low voltage SKUs are limited to max of 5.4G */
> - if (voltage == VOLTAGE_INFO_0_85V)
> - return 54;
> -
> - /* For this SKU 8.1G is supported in all ports */
> - if (IS_CNL_WITH_PORT_F(dev_priv))
> - return 81;
> -
> - /* For other SKUs, max rate on ports A and D is 5.4G */
> - if (port == PORT_A || port == PORT_D)
> - return 54;
> -
> - return 81;
> -}
> -
> static int icl_max_source_rate(struct intel_dp *intel_dp)
> {
> struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> @@ -270,7 +247,7 @@ static void
> intel_dp_set_source_rates(struct intel_dp *intel_dp)
> {
> /* The values must be in increasing order */
> - static const int cnl_rates[] = {
> + static const int icl_rates[] = {
> 162000, 216000, 27, 324000, 432000, 54, 648000, 81
> };
> static const int bxt_rates[] = {
> @@ -295,12 +272,10 @@ intel_dp_set_source_rates(struct intel_dp *intel_dp)
> drm_WARN_ON(&dev_priv->drm,
> intel_dp->source_rates || intel_dp->num_source_rates);
>
> - if (DISPLAY_VER(dev_priv) >= 11 || IS_CANNONLAKE(dev_priv)) {
> - source_rates = cnl_rates;
> - size = ARRAY_SIZE(cnl_rates);
> - if (DISPLAY_VER(dev_priv) == 10)
> - max_rate = cnl_max_source_rate(intel_dp);
> - else if (IS_JSL_EHL(dev_priv))
> + if (DISPLAY_VER(dev_priv) >= 11) {
> + source_rates = icl_rates;
> + size = ARRAY_SIZE(icl_rates);
> + if (IS_JSL_EHL(dev_priv))
> max_rate = ehl_max_source_rate(intel_dp);
> else
> max_rate = icl_max_source_rate(intel_dp);
> --
> 2.31.1
>
Re: [Intel-gfx] [PATCH 16/30] drm/i915/display: remove CNL ddi buf translation tables
On Fri, Jul 23, 2021 at 05:11:00PM -0700, Lucas De Marchi wrote:
> The only real platform with DISPLAY_VER == 10 is GLK. We don't need to
> handle CNL explicitly.
>
> Signed-off-by: Lucas De Marchi
Reviewed-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/display/intel_ddi.c | 12 +-
> .../drm/i915/display/intel_ddi_buf_trans.c| 616 +-
> .../drm/i915/display/intel_ddi_buf_trans.h| 4 +-
> 3 files changed, 184 insertions(+), 448 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index 8367462842fa..e5cfb606dd30 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -1055,8 +1055,8 @@ static void icl_ddi_combo_vswing_program(struct
> intel_encoder *encoder,
> val = intel_de_read(dev_priv, ICL_PORT_TX_DW2_LN0(phy));
> val &= ~(SWING_SEL_LOWER_MASK | SWING_SEL_UPPER_MASK |
>RCOMP_SCALAR_MASK);
> - val |=
> SWING_SEL_UPPER(ddi_translations->entries[level].cnl.dw2_swing_sel);
> - val |=
> SWING_SEL_LOWER(ddi_translations->entries[level].cnl.dw2_swing_sel);
> + val |=
> SWING_SEL_UPPER(ddi_translations->entries[level].icl.dw2_swing_sel);
> + val |=
> SWING_SEL_LOWER(ddi_translations->entries[level].icl.dw2_swing_sel);
> /* Program Rcomp scalar for every table entry */
> val |= RCOMP_SCALAR(0x98);
> intel_de_write(dev_priv, ICL_PORT_TX_DW2_GRP(phy), val);
> @@ -1067,16 +1067,16 @@ static void icl_ddi_combo_vswing_program(struct
> intel_encoder *encoder,
> val = intel_de_read(dev_priv, ICL_PORT_TX_DW4_LN(ln, phy));
> val &= ~(POST_CURSOR_1_MASK | POST_CURSOR_2_MASK |
>CURSOR_COEFF_MASK);
> - val |=
> POST_CURSOR_1(ddi_translations->entries[level].cnl.dw4_post_cursor_1);
> - val |=
> POST_CURSOR_2(ddi_translations->entries[level].cnl.dw4_post_cursor_2);
> - val |=
> CURSOR_COEFF(ddi_translations->entries[level].cnl.dw4_cursor_coeff);
> + val |=
> POST_CURSOR_1(ddi_translations->entries[level].icl.dw4_post_cursor_1);
> + val |=
> POST_CURSOR_2(ddi_translations->entries[level].icl.dw4_post_cursor_2);
> + val |=
> CURSOR_COEFF(ddi_translations->entries[level].icl.dw4_cursor_coeff);
> intel_de_write(dev_priv, ICL_PORT_TX_DW4_LN(ln, phy), val);
> }
>
> /* Program PORT_TX_DW7 */
> val = intel_de_read(dev_priv, ICL_PORT_TX_DW7_LN0(phy));
> val &= ~N_SCALAR_MASK;
> - val |= N_SCALAR(ddi_translations->entries[level].cnl.dw7_n_scalar);
> + val |= N_SCALAR(ddi_translations->entries[level].icl.dw7_n_scalar);
> intel_de_write(dev_priv, ICL_PORT_TX_DW7_GRP(phy), val);
> }
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c
> b/drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c
> index 63b1ae830d9a..9ab95bcd0c86 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c
> @@ -417,199 +417,19 @@ static const struct intel_ddi_buf_trans
> bxt_ddi_translations_hdmi = {
> .hdmi_default_entry = ARRAY_SIZE(_bxt_ddi_translations_hdmi) - 1,
> };
>
> -/* Voltage Swing Programming for VccIO 0.85V for DP */
> -static const union intel_ddi_buf_trans_entry
> _cnl_ddi_translations_dp_0_85V[] = {
> - /* NT mV Trans mV db
> */
> - { .cnl = { 0xA, 0x5D, 0x3F, 0x00, 0x00 } }, /* 350 350 0.0
> */
> - { .cnl = { 0xA, 0x6A, 0x38, 0x00, 0x07 } }, /* 350 500 3.1
> */
> - { .cnl = { 0xB, 0x7A, 0x32, 0x00, 0x0D } }, /* 350 700 6.0
> */
> - { .cnl = { 0x6, 0x7C, 0x2D, 0x00, 0x12 } }, /* 350 900 8.2
> */
> - { .cnl = { 0xA, 0x69, 0x3F, 0x00, 0x00 } }, /* 500 500 0.0
> */
> - { .cnl = { 0xB, 0x7A, 0x36, 0x00, 0x09 } }, /* 500 700 2.9
> */
> - { .cnl = { 0x6, 0x7C, 0x30, 0x00, 0x0F } }, /* 500 900 5.1
> */
> - { .cnl = { 0xB, 0x7D, 0x3C, 0x00, 0x03 } }, /* 650 725 0.9
> */
> - { .cnl = { 0x6, 0x7C, 0x34, 0x00, 0x0B } }, /* 600 900 3.5
> */
> - { .cnl = { 0x6, 0x7B, 0x3F, 0x00, 0x00 } }, /* 900 900 0.0
> */
> -};
> -
> -static const struct intel_ddi_buf_trans cnl_ddi_translations_dp_0_85V = {
> - .entries = _cnl_ddi_translations_dp_0_85V,
> - .num_entries = ARRAY_SIZE(_cnl_ddi_translations_dp_0_85V),
> -};
> -
> -/* Voltage Swing Programming for VccIO 0.85V for HDMI */
> -static const union intel_ddi_buf_trans_entry
> _cnl_ddi_translations_hdmi_0_85V[] = {
> - /* NT mV Trans mV db
> */
> - { .cnl = { 0xA, 0x60, 0x3F, 0x00, 0x00 } }, /* 450 450 0.0
> */
> - { .cnl = { 0xB, 0x73, 0x36, 0x00, 0x09 } }, /* 450 650 3.2
> */
> - { .c
Re: [Intel-gfx] [PATCH 22/30] drm/i915: remove explicit CNL handling from intel_wopcm.c
On Fri, Jul 23, 2021 at 05:11:06PM -0700, Lucas De Marchi wrote:
> Consider the new WOPCM size as starting in ICL rather than CNL since the
> latter is being removed from the driver.
>
> Signed-off-by: Lucas De Marchi
Reviewed-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/intel_wopcm.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_wopcm.c
> b/drivers/gpu/drm/i915/intel_wopcm.c
> index 8309455f13ea..5e511bb891f9 100644
> --- a/drivers/gpu/drm/i915/intel_wopcm.c
> +++ b/drivers/gpu/drm/i915/intel_wopcm.c
> @@ -56,8 +56,8 @@
>
> /* 24KB at the end of WOPCM is reserved for RC6 CTX on BXT. */
> #define BXT_WOPCM_RC6_CTX_RESERVED (SZ_16K + SZ_8K)
> -/* 36KB WOPCM reserved at the end of WOPCM on CNL. */
> -#define CNL_WOPCM_HW_CTX_RESERVED(SZ_32K + SZ_4K)
> +/* 36KB WOPCM reserved at the end of WOPCM on ICL. */
> +#define ICL_WOPCM_HW_CTX_RESERVED(SZ_32K + SZ_4K)
>
> /* 128KB from GUC_WOPCM_RESERVED is reserved for FW on Gen9. */
> #define GEN9_GUC_FW_RESERVED SZ_128K
> @@ -93,8 +93,8 @@ static u32 context_reserved_size(struct drm_i915_private
> *i915)
> {
> if (IS_GEN9_LP(i915))
> return BXT_WOPCM_RC6_CTX_RESERVED;
> - else if (GRAPHICS_VER(i915) >= 10)
> - return CNL_WOPCM_HW_CTX_RESERVED;
> + else if (GRAPHICS_VER(i915) >= 11)
> + return ICL_WOPCM_HW_CTX_RESERVED;
> else
> return 0;
> }
> @@ -126,7 +126,7 @@ static bool gen9_check_huc_fw_fits(struct
> drm_i915_private *i915,
> u32 guc_wopcm_size, u32 huc_fw_size)
> {
> /*
> - * On Gen9 & CNL A0, hardware requires the total available GuC WOPCM
> + * On Gen9, hardware requires the total available GuC WOPCM
>* size to be larger than or equal to HuC firmware size. Otherwise,
>* firmware uploading would fail.
>*/
> --
> 2.31.1
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [PATCH 18/30] drm/i915: remove explicit CNL handling from i915_irq.c
On Fri, Jul 23, 2021 at 05:11:02PM -0700, Lucas De Marchi wrote:
> Remove special handling of PORT_F in i915_irq.c and only do it for
> DISPLAY_VER == 11.
oh! ignore my previous thought about removing the port F...
>
> Signed-off-by: Lucas De Marchi
Reviewed-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/i915_irq.c | 7 +++
> drivers/gpu/drm/i915/i915_reg.h | 2 +-
> 2 files changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index e2171bd2820e..17d336218b67 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -2297,11 +2297,10 @@ static u32 gen8_de_port_aux_mask(struct
> drm_i915_private *dev_priv)
> GEN9_AUX_CHANNEL_C |
> GEN9_AUX_CHANNEL_D;
>
> - if (IS_CNL_WITH_PORT_F(dev_priv) || DISPLAY_VER(dev_priv) == 11)
> - mask |= CNL_AUX_CHANNEL_F;
> -
> - if (DISPLAY_VER(dev_priv) == 11)
> + if (DISPLAY_VER(dev_priv) == 11) {
> + mask |= ICL_AUX_CHANNEL_F;
> mask |= ICL_AUX_CHANNEL_E;
> + }
>
> return mask;
> }
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index d198b1a2d4b5..fdc8fd424d36 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -7945,7 +7945,7 @@ enum {
> #define DSI1_NON_TE (1 << 31)
> #define DSI0_NON_TE (1 << 30)
> #define ICL_AUX_CHANNEL_E (1 << 29)
> -#define CNL_AUX_CHANNEL_F (1 << 28)
> +#define ICL_AUX_CHANNEL_F (1 << 28)
> #define GEN9_AUX_CHANNEL_D (1 << 27)
> #define GEN9_AUX_CHANNEL_C (1 << 26)
> #define GEN9_AUX_CHANNEL_B (1 << 25)
> --
> 2.31.1
>
Re: [Intel-gfx] [PATCH 08/30] drm/i915/display: remove explicit CNL handling from intel_ddi.c
On Fri, Jul 23, 2021 at 05:10:52PM -0700, Lucas De Marchi wrote:
> The only real platform with DISPLAY_VER == 10 is GLK. We don't need to
> handle CNL explicitly in intel_ddi.c.
>
> Remove code and rename functions/macros accordingly to use ICL prefix.
> There's one leftover reference to cnl that comes from the struct
> intel_ddi_buf_trans. This will be renamed later when we get rid of the
> additional CNL tables.
>
> Signed-off-by: Lucas De Marchi
Reviewed-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/display/intel_ddi.c | 254 ++-
> 1 file changed, 20 insertions(+), 234 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index 26a3aa73fcc4..8367462842fa 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -822,7 +822,7 @@ bool intel_ddi_get_hw_state(struct intel_encoder *encoder,
> static enum intel_display_power_domain
> intel_ddi_main_link_aux_domain(struct intel_digital_port *dig_port)
> {
> - /* CNL+ HW requires corresponding AUX IOs to be powered up for PSR with
> + /* ICL+ HW requires corresponding AUX IOs to be powered up for PSR with
>* DC states enabled at the same time, while for driver initiated AUX
>* transfers we need the same AUX IOs to be powered but with DC states
>* disabled. Accordingly use the AUX power domain here which leaves DC
> @@ -1017,126 +1017,6 @@ static u8 intel_ddi_dp_preemph_max(struct intel_dp
> *intel_dp)
> return DP_TRAIN_PRE_EMPH_LEVEL_3;
> }
>
> -static void cnl_ddi_vswing_program(struct intel_encoder *encoder,
> -const struct intel_crtc_state *crtc_state,
> -int level)
> -{
> - struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> - const struct intel_ddi_buf_trans *ddi_translations;
> - enum port port = encoder->port;
> - int n_entries, ln;
> - u32 val;
> -
> - ddi_translations = encoder->get_buf_trans(encoder, crtc_state,
> &n_entries);
> - if (drm_WARN_ON_ONCE(&dev_priv->drm, !ddi_translations))
> - return;
> - if (drm_WARN_ON_ONCE(&dev_priv->drm, level >= n_entries))
> - level = n_entries - 1;
> -
> - /* Set PORT_TX_DW5 Scaling Mode Sel to 010b. */
> - val = intel_de_read(dev_priv, CNL_PORT_TX_DW5_LN0(port));
> - val &= ~SCALING_MODE_SEL_MASK;
> - val |= SCALING_MODE_SEL(2);
> - intel_de_write(dev_priv, CNL_PORT_TX_DW5_GRP(port), val);
> -
> - /* Program PORT_TX_DW2 */
> - val = intel_de_read(dev_priv, CNL_PORT_TX_DW2_LN0(port));
> - val &= ~(SWING_SEL_LOWER_MASK | SWING_SEL_UPPER_MASK |
> - RCOMP_SCALAR_MASK);
> - val |=
> SWING_SEL_UPPER(ddi_translations->entries[level].cnl.dw2_swing_sel);
> - val |=
> SWING_SEL_LOWER(ddi_translations->entries[level].cnl.dw2_swing_sel);
> - /* Rcomp scalar is fixed as 0x98 for every table entry */
> - val |= RCOMP_SCALAR(0x98);
> - intel_de_write(dev_priv, CNL_PORT_TX_DW2_GRP(port), val);
> -
> - /* Program PORT_TX_DW4 */
> - /* We cannot write to GRP. It would overrite individual loadgen */
> - for (ln = 0; ln < 4; ln++) {
> - val = intel_de_read(dev_priv, CNL_PORT_TX_DW4_LN(ln, port));
> - val &= ~(POST_CURSOR_1_MASK | POST_CURSOR_2_MASK |
> - CURSOR_COEFF_MASK);
> - val |=
> POST_CURSOR_1(ddi_translations->entries[level].cnl.dw4_post_cursor_1);
> - val |=
> POST_CURSOR_2(ddi_translations->entries[level].cnl.dw4_post_cursor_2);
> - val |=
> CURSOR_COEFF(ddi_translations->entries[level].cnl.dw4_cursor_coeff);
> - intel_de_write(dev_priv, CNL_PORT_TX_DW4_LN(ln, port), val);
> - }
> -
> - /* Program PORT_TX_DW5 */
> - /* All DW5 values are fixed for every table entry */
> - val = intel_de_read(dev_priv, CNL_PORT_TX_DW5_LN0(port));
> - val &= ~RTERM_SELECT_MASK;
> - val |= RTERM_SELECT(6);
> - val |= TAP3_DISABLE;
> - intel_de_write(dev_priv, CNL_PORT_TX_DW5_GRP(port), val);
> -
> - /* Program PORT_TX_DW7 */
> - val = intel_de_read(dev_priv, CNL_PORT_TX_DW7_LN0(port));
> - val &= ~N_SCALAR_MASK;
> - val |= N_SCALAR(ddi_translations->entries[level].cnl.dw7_n_scalar);
> - intel_de_write(dev_priv, CNL_PORT_TX_DW7_GRP(port), val);
> -}
> -
> -static void cnl_ddi_vswing_sequence(struct intel_encoder *encoder,
> - const struct intel_crtc_state *crtc_state,
> - int level)
> -{
> - struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> - enum port port = encoder->port;
> - int width, rate, ln;
> - u32 val;
> -
> - width = crtc_state->lane_count;
> - rate = crtc_state->port_clock;
> -
> - /*
> - * 1. If port type is eDP or DP,
> - * set PORT_PCS_DW1 cmnkeeper_enable to 1b,
> -
Re: [Intel-gfx] [PATCH 13/30] drm/i915/display: remove explicit CNL handling from intel_vdsc.c
On Fri, Jul 23, 2021 at 05:10:57PM -0700, Lucas De Marchi wrote: > Only one reference to CNL that is not needed, but code is the same for > DISPLAY_VER >= 11, so leave the code around and just remove the special > case for CNL. > > Signed-off-by: Lucas De Marchi Reviewed-by: Rodrigo Vivi > --- > drivers/gpu/drm/i915/display/intel_vdsc.c | 5 - > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/display/intel_vdsc.c > b/drivers/gpu/drm/i915/display/intel_vdsc.c > index 85749370508c..df3286aa6999 100644 > --- a/drivers/gpu/drm/i915/display/intel_vdsc.c > +++ b/drivers/gpu/drm/i915/display/intel_vdsc.c > @@ -348,7 +348,10 @@ bool intel_dsc_source_support(const struct > intel_crtc_state *crtc_state) > if (DISPLAY_VER(i915) >= 12) > return true; > > - if ((DISPLAY_VER(i915) >= 11 || IS_CANNONLAKE(i915)) && (pipe != PIPE_A > || (cpu_transcoder == TRANSCODER_EDP || cpu_transcoder == TRANSCODER_DSI_0 || > cpu_transcoder == TRANSCODER_DSI_1))) > + if (DISPLAY_VER(i915) >= 11 && > + (pipe != PIPE_A || cpu_transcoder == TRANSCODER_EDP || > + cpu_transcoder == TRANSCODER_DSI_0 || > + cpu_transcoder == TRANSCODER_DSI_1)) > return true; > > return false; > -- > 2.31.1 > > ___ > Intel-gfx mailing list > intel-...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 10/30] drm/i915/display: remove explicit CNL handling from intel_dmc.c
On Fri, Jul 23, 2021 at 05:10:54PM -0700, Lucas De Marchi wrote:
> Remove DMC firmware for CNL.
>
> Signed-off-by: Lucas De Marchi
Cc: Anusha Srivatsa
We need to remove the binary from linux-firmware.git as well
> ---
> drivers/gpu/drm/i915/display/intel_dmc.c | 9 -
> 1 file changed, 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c
> b/drivers/gpu/drm/i915/display/intel_dmc.c
> index 9895fd957df9..3c3c6cb5c0df 100644
> --- a/drivers/gpu/drm/i915/display/intel_dmc.c
> +++ b/drivers/gpu/drm/i915/display/intel_dmc.c
> @@ -70,11 +70,6 @@ MODULE_FIRMWARE(TGL_DMC_PATH);
> #define ICL_DMC_MAX_FW_SIZE 0x6000
> MODULE_FIRMWARE(ICL_DMC_PATH);
>
> -#define CNL_DMC_PATH DMC_PATH(cnl, 1, 07)
> -#define CNL_DMC_VERSION_REQUIRED DMC_VERSION(1, 7)
> -#define CNL_DMC_MAX_FW_SIZE GLK_DMC_MAX_FW_SIZE
> -MODULE_FIRMWARE(CNL_DMC_PATH);
> -
> #define GLK_DMC_PATH DMC_PATH(glk, 1, 04)
> #define GLK_DMC_VERSION_REQUIRED DMC_VERSION(1, 4)
> #define GLK_DMC_MAX_FW_SIZE 0x4000
> @@ -718,10 +713,6 @@ void intel_dmc_ucode_init(struct drm_i915_private
> *dev_priv)
> dmc->fw_path = ICL_DMC_PATH;
> dmc->required_version = ICL_DMC_VERSION_REQUIRED;
> dmc->max_fw_size = ICL_DMC_MAX_FW_SIZE;
> - } else if (IS_CANNONLAKE(dev_priv)) {
> - dmc->fw_path = CNL_DMC_PATH;
> - dmc->required_version = CNL_DMC_VERSION_REQUIRED;
> - dmc->max_fw_size = CNL_DMC_MAX_FW_SIZE;
> } else if (IS_GEMINILAKE(dev_priv)) {
> dmc->fw_path = GLK_DMC_PATH;
> dmc->required_version = GLK_DMC_VERSION_REQUIRED;
> --
> 2.31.1
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 09/30] drm/i915/display: remove explicit CNL handling from intel_display_debugfs.c
On Fri, Jul 23, 2021 at 05:10:53PM -0700, Lucas De Marchi wrote:
> Only one reference to CNL that is not needed, but code is the same for
> DISPLAY_VER >= 11, so leave the code around and just remove the special
> case for CNL.
>
> Signed-off-by: Lucas De Marchi
Reviewed-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/display/intel_display_debugfs.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> index 2cf742a0b957..8fdacb252bb1 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> @@ -2500,7 +2500,7 @@ int intel_connector_debugfs_add(struct drm_connector
> *connector)
> connector, &i915_hdcp_sink_capability_fops);
> }
>
> - if ((DISPLAY_VER(dev_priv) >= 11 || IS_CANNONLAKE(dev_priv)) &&
> + if (DISPLAY_VER(dev_priv) >= 11 &&
> ((connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort &&
> !to_intel_connector(connector)->mst_port) ||
> connector->connector_type == DRM_MODE_CONNECTOR_eDP)) {
> --
> 2.31.1
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 19/30] drm/i915: remove explicit CNL handling from intel_pm.c
On Fri, Jul 23, 2021 at 05:11:03PM -0700, Lucas De Marchi wrote:
> Remove support for CNL as it's highly untested, probably broken, and
> there is no real platform that requires this code. This is part of CNL
> removal from i915.
>
> Signed-off-by: Lucas De Marchi
Reviewed-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/i915_reg.h | 2 +-
> drivers/gpu/drm/i915/intel_pm.c | 41 +
> 2 files changed, 2 insertions(+), 41 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index fdc8fd424d36..f032a4c8b26d 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -8239,7 +8239,7 @@ enum {
>
> #define GEN8_CHICKEN_DCPR_1 _MMIO(0x46430)
> #define SKL_SELECT_ALTERNATE_DC_EXIT (1 << 30)
> -#define CNL_DELAY_PMRSP(1 << 22)
> +#define ICL_DELAY_PMRSP(1 << 22)
> #define MASK_WAKEMEM (1 << 13)
> #define CNL_DDI_CLOCK_REG_ACCESS_ON(1 << 7)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index aa64b2ef2efb..65bc3709f54c 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -7465,7 +7465,7 @@ static void icl_init_clock_gating(struct
> drm_i915_private *dev_priv)
>
> /*Wa_14010594013:icl, ehl */
> intel_uncore_rmw(&dev_priv->uncore, GEN8_CHICKEN_DCPR_1,
> - 0, CNL_DELAY_PMRSP);
> + 0, ICL_DELAY_PMRSP);
> }
>
> static void gen12lp_init_clock_gating(struct drm_i915_private *dev_priv)
> @@ -7515,43 +7515,6 @@ static void cnp_init_clock_gating(struct
> drm_i915_private *dev_priv)
> CNP_PWM_CGE_GATING_DISABLE);
> }
>
> -static void cnl_init_clock_gating(struct drm_i915_private *dev_priv)
> -{
> - u32 val;
> - cnp_init_clock_gating(dev_priv);
> -
> - /* This is not an Wa. Enable for better image quality */
> - intel_uncore_write(&dev_priv->uncore, _3D_CHICKEN3,
> -_MASKED_BIT_ENABLE(_3D_CHICKEN3_AA_LINE_QUALITY_FIX_ENABLE));
> -
> - /* WaEnableChickenDCPR:cnl */
> - intel_uncore_write(&dev_priv->uncore, GEN8_CHICKEN_DCPR_1,
> -intel_uncore_read(&dev_priv->uncore, GEN8_CHICKEN_DCPR_1) |
> MASK_WAKEMEM);
> -
> - /*
> - * WaFbcWakeMemOn:cnl
> - * Display WA #0859: cnl
> - */
> - intel_uncore_write(&dev_priv->uncore, DISP_ARB_CTL,
> intel_uncore_read(&dev_priv->uncore, DISP_ARB_CTL) |
> -DISP_FBC_MEMORY_WAKE);
> -
> - val = intel_uncore_read(&dev_priv->uncore, SLICE_UNIT_LEVEL_CLKGATE);
> - /* ReadHitWriteOnlyDisable:cnl */
> - val |= RCCUNIT_CLKGATE_DIS;
> - intel_uncore_write(&dev_priv->uncore, SLICE_UNIT_LEVEL_CLKGATE, val);
> -
> - /* Wa_2201832410:cnl */
> - val = intel_uncore_read(&dev_priv->uncore, SUBSLICE_UNIT_LEVEL_CLKGATE);
> - val |= GWUNIT_CLKGATE_DIS;
> - intel_uncore_write(&dev_priv->uncore, SUBSLICE_UNIT_LEVEL_CLKGATE, val);
> -
> - /* WaDisableVFclkgate:cnl */
> - /* WaVFUnitClockGatingDisable:cnl */
> - val = intel_uncore_read(&dev_priv->uncore, UNSLICE_UNIT_LEVEL_CLKGATE);
> - val |= VFUNIT_CLKGATE_DIS;
> - intel_uncore_write(&dev_priv->uncore, UNSLICE_UNIT_LEVEL_CLKGATE, val);
> -}
> -
> static void cfl_init_clock_gating(struct drm_i915_private *dev_priv)
> {
> cnp_init_clock_gating(dev_priv);
> @@ -7980,8 +7943,6 @@ void intel_init_clock_gating_hooks(struct
> drm_i915_private *dev_priv)
> dev_priv->display.init_clock_gating = gen12lp_init_clock_gating;
> else if (GRAPHICS_VER(dev_priv) == 11)
> dev_priv->display.init_clock_gating = icl_init_clock_gating;
> - else if (IS_CANNONLAKE(dev_priv))
> - dev_priv->display.init_clock_gating = cnl_init_clock_gating;
> else if (IS_COFFEELAKE(dev_priv) || IS_COMETLAKE(dev_priv))
> dev_priv->display.init_clock_gating = cfl_init_clock_gating;
> else if (IS_SKYLAKE(dev_priv))
> --
> 2.31.1
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [PATCH v3 3/3] drm/panel-simple: add Gopher 2b LCD panel
Hello, Paul!
Thanks for your investigation.
But while this two panels are compatible with the timing set in the
driver, their timing ranges are different ([1], [2]) and therefore
should have different compatible strings.
[1]: https://wendangmao.net/doc/753b5635102de2bd960588e2-51.html
[2]: https://www.newhavendisplay.com/appnotes/datasheets/LCDs/ST7282.pdf
Artjom.
On 26/07/2021 12.02, Paul Cercueil wrote:
Hi Artjom,
Le lun., juil. 26 2021 at 01:15:27 +0300, Artjom Vejsel
a écrit :
The Gopher 2b LCD panel is used in Gopher 2b handhelds.
It's simple panel with NewVision NV3047 driver, but SPI lines are not
connected.
It has no specific name, since it's unique to that handhelds.
lot name at AliExpress: 4.3 inch 40PIN TFT LCD Screen COG NV3047
Drive IC 480(RGB)*272 No Touch 24Bit RGB Interface
From what I gathered the Gopher2's LCD panel is the exact same that is
inside the RS-07 handheld. According to the teardown (in [1]), the
RS-07 panel is a Amelin AML043056B0-40 (see [2]).
Could you verify that? According to the photos, the product code is
written on the flexible connector.
If that's the case, instead of using the
"qishenglong,gopher2b-lcd-panel" compatible string, could you use
"amelin,aml043056b0-40"?
Cheers,
-Paul
[1]: https://steward-fu.github.io/website/handheld/rs07/teardown.htm
[2]: http://www.amelin.com.cn/en/h-pd-355.html
Signed-off-by: Artjom Vejsel
---
drivers/gpu/drm/panel/panel-simple.c | 43
1 file changed, 43 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 9b286bdf..6b69c0c70814 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -3563,6 +3563,46 @@ static const struct panel_desc qd43003c0_40 = {
.bus_format = MEDIA_BUS_FMT_RGB888_1X24,
};
+static const struct drm_display_mode
qishenglong_gopher2b_lcd_panel_modes[] = {
+ { /* 60 Hz */
+ .clock = 10800,
+ .hdisplay = 480,
+ .hsync_start = 480 + 77,
+ .hsync_end = 480 + 77 + 41,
+ .htotal = 480 + 77 + 41 + 2,
+ .vdisplay = 272,
+ .vsync_start = 272 + 16,
+ .vsync_end = 272 + 16 + 10,
+ .vtotal = 272 + 16 + 10 + 2,
+ .flags = DRM_MODE_FLAG_NVSYNC | DRM_MODE_FLAG_NHSYNC,
+ },
+ { /* 50 Hz */
+ .clock = 10800,
+ .hdisplay = 480,
+ .hsync_start = 480 + 17,
+ .hsync_end = 480 + 17 + 41,
+ .htotal = 480 + 17 + 41 + 2,
+ .vdisplay = 272,
+ .vsync_start = 272 + 116,
+ .vsync_end = 272 + 116 + 10,
+ .vtotal = 272 + 116 + 10 + 2,
+ .flags = DRM_MODE_FLAG_NVSYNC | DRM_MODE_FLAG_NHSYNC,
+ },
+};
+
+static const struct panel_desc qishenglong_gopher2b_lcd_panel = {
+ .modes = qishenglong_gopher2b_lcd_panel_modes,
+ .num_modes = ARRAY_SIZE(qishenglong_gopher2b_lcd_panel_modes),
+ .bpc = 8,
+ .size = {
+ .width = 95,
+ .height = 54,
+ },
+ .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
+ .bus_flags = DRM_BUS_FLAG_DE_HIGH |
DRM_BUS_FLAG_PIXDATA_SAMPLE_NEGEDGE,
+ .connector_type = DRM_MODE_CONNECTOR_DPI,
+};
+
static const struct display_timing rocktech_rk070er9427_timing = {
.pixelclock = { 2640, 3330, 4680 },
.hactive = { 800, 800, 800 },
@@ -4651,6 +4691,9 @@ static const struct of_device_id
platform_of_match[] = {
}, {
.compatible = "qiaodian,qd43003c0-40",
.data = &qd43003c0_40,
+ }, {
+ .compatible = "qishenglong,gopher2b-lcd-panel",
+ .data = &qishenglong_gopher2b_lcd_panel,
}, {
.compatible = "rocktech,rk070er9427",
.data = &rocktech_rk070er9427,
--
2.32.0
Re: [PATCH] drm/fourcc: Add modifier definitions for Arm Fixed Rate Compression
On Thu, Jul 01, 2021 at 06:07:09PM +0100, Normunds Rieksts wrote: > Arm Fixed Rate Compression (AFRC) is a proprietary fixed rate image > compression protocol and format. > It is designed to provide guaranteed bandwidth and memory footprint > reductions in graphics and media use-cases. > > This patch aims to add modifier definitions for describing > AFRC. > > Signed-off-by: Normunds Rieksts Applied to drm-misc-next. Best regards, Liviu > --- > include/uapi/drm/drm_fourcc.h | 109 +- > 1 file changed, 106 insertions(+), 3 deletions(-) > > diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h > index f7156322aba5..9f4bb4a6f358 100644 > --- a/include/uapi/drm/drm_fourcc.h > +++ b/include/uapi/drm/drm_fourcc.h > @@ -900,9 +900,9 @@ drm_fourcc_canonicalize_nvidia_format_mod(__u64 modifier) > > /* > * The top 4 bits (out of the 56 bits alloted for specifying vendor specific > - * modifiers) denote the category for modifiers. Currently we have only two > - * categories of modifiers ie AFBC and MISC. We can have a maximum of sixteen > - * different categories. > + * modifiers) denote the category for modifiers. Currently we have three > + * categories of modifiers ie AFBC, MISC and AFRC. We can have a maximum of > + * sixteen different categories. > */ > #define DRM_FORMAT_MOD_ARM_CODE(__type, __val) \ > fourcc_mod_code(ARM, ((__u64)(__type) << 52) | ((__val) & > 0x000fULL)) > @@ -1017,6 +1017,109 @@ drm_fourcc_canonicalize_nvidia_format_mod(__u64 > modifier) > */ > #define AFBC_FORMAT_MOD_USM (1ULL << 12) > > +/* > + * Arm Fixed-Rate Compression (AFRC) modifiers > + * > + * AFRC is a proprietary fixed rate image compression protocol and format, > + * designed to provide guaranteed bandwidth and memory footprint > + * reductions in graphics and media use-cases. > + * > + * AFRC buffers consist of one or more planes, with the same components > + * and meaning as an uncompressed buffer using the same pixel format. > + * > + * Within each plane, the pixel/luma/chroma values are grouped into > + * "coding unit" blocks which are individually compressed to a > + * fixed size (in bytes). All coding units within a given plane of a buffer > + * store the same number of values, and have the same compressed size. > + * > + * The coding unit size is configurable, allowing different rates of > compression. > + * > + * The start of each AFRC buffer plane must be aligned to an alignment > granule which > + * depends on the coding unit size. > + * > + * Coding Unit Size Plane Alignment > + * --- > + * 16 bytes 1024 bytes > + * 24 bytes 512 bytes > + * 32 bytes 2048 bytes > + * > + * Coding units are grouped into paging tiles. AFRC buffer dimensions must > be aligned > + * to a multiple of the paging tile dimensions. > + * The dimensions of each paging tile depend on whether the buffer is > optimised for > + * scanline (SCAN layout) or rotated (ROT layout) access. > + * > + * Layout Paging Tile Width Paging Tile Height > + * -- - -- > + * SCAN 16 coding units 4 coding units > + * ROT 8 coding units 8 coding units > + * > + * The dimensions of each coding unit depend on the number of components > + * in the compressed plane and whether the buffer is optimised for > + * scanline (SCAN layout) or rotated (ROT layout) access. > + * > + * Number of Components in Plane Layout Coding Unit Width Coding > Unit Height > + * - - - > -- > + * 1 SCAN16 samples 4 samples > + * Example: 16x4 luma samples in a 'Y' plane > + * 16x4 chroma 'V' values, in the 'V' plane of a fully-planar YUV > buffer > + * - - - > -- > + * 1 ROT 8 samples 8 samples > + * Example: 8x8 luma samples in a 'Y' plane > + * 8x8 chroma 'V' values, in the 'V' plane of a fully-planar YUV > buffer > + * - - - > -- > + * 2 DONT CARE 8 samples 4 samples > + * Example: 8x4 chroma pairs in the 'UV' plane of a semi-planar YUV buffer > + * - - - > -- > + * 3 DONT CARE 4 samples 4 samples > + * Example: 4x4 pixels in an RGB buffer without alpha > + * - - - > -- > + * 4 DONT CARE 4 samples 4 samples > + * Example: 4x4 pixels in an RGB buffer with alpha > + */ > + > +#define DRM_FORMAT_MOD_ARM_TYPE_AFRC 0x02 > + > +#define DRM_FORMAT_MOD_ARM_AFRC(__afr
Re: [PATCH] fbcon: Out-Of-Bounds write in sys_imageblit, add range check
On Mon, Jul 26, 2021 at 11:32:37AM +, tcs_kernel(腾讯云内核开发者) wrote: > yres and vyres can be controlled by user mode paramaters, and cause p->vrows > to become a negative value. While this value be passed to real_y function, > the ypos will be out of screen range. > This is an out-of-bounds write bug. > > > diff --git a/drivers/video/fbdev/core/fbcon.c > b/drivers/video/fbdev/core/fbcon.c > index 22bb3892f6bd..0970de46782f 100644 > --- a/drivers/video/fbdev/core/fbcon.c > +++ b/drivers/video/fbdev/core/fbcon.c > @@ -1956,11 +1956,12 @@ static void updatescrollmode(struct fbcon_display *p, > int yres = FBCON_SWAP(ops->rotate, info->var.yres, info->var.xres); > int vyres = FBCON_SWAP(ops->rotate, info->var.yres_virtual, >info->var.xres_virtual); > + int rows = vc->vc_rows; > > p->vrows = vyres/fh; > - if (yres > (fh * (vc->vc_rows + 1))) > - p->vrows -= (yres - (fh * vc->vc_rows)) / fh; > - if ((yres % fh) && (vyres % fh < yres % fh)) > + if ((yres > (fh * (rows + 1))) && (vyres >= (yres - (fh * rows))) && > p->vrows) > + p->vrows -= (yres - (fh * rows)) / fh; > + if ((yres % fh) && (vyres % fh < yres % fh) && p->vrows) > p->vrows--; > } > Hi, This is the friendly patch-bot of Greg Kroah-Hartman. You have sent him a patch that has triggered this response. He used to manually respond to these common problems, but in order to save his sanity (he kept writing the same thing over and over, yet to different people), I was created. Hopefully you will not take offence and will fix the problem in your patch and resubmit it so that it can be accepted into the Linux kernel tree. You are receiving this message because of the following common error(s) as indicated below: - Your patch is malformed (tabs converted to spaces, linewrapped, etc.) and can not be applied. Please read the file, Documentation/email-clients.txt in order to fix this. - Your patch does not have a Signed-off-by: line. Please read the kernel file, Documentation/SubmittingPatches and resend it after adding that line. Note, the line needs to be in the body of the email, before the patch, not at the bottom of the patch or in the email signature. - You did not specify a description of why the patch is needed, or possibly, any description at all, in the email body. Please read the section entitled "The canonical patch format" in the kernel file, Documentation/SubmittingPatches for what is needed in order to properly describe the change. If you wish to discuss this problem further, or you have questions about how to resolve this issue, please feel free to respond to this email and Greg will reply once he has dug out from the pending patches received from other developers. thanks, greg k-h's patch email bot
Re: [PATCH v2] drm/dsi: Add _NO_ to MIPI_DSI_* flags disabling features
Hi Nicolas, On Mon, Jul 26, 2021 at 08:38:18AM +0800, Nicolas Boichat wrote: > On Sun, Jul 25, 2021 at 9:31 PM Sam Ravnborg wrote: > > > > On Tue, Jun 29, 2021 at 07:47:21AM +0800, Nicolas Boichat wrote: > > > Many of the DSI flags have names opposite to their actual effects, > > > e.g. MIPI_DSI_MODE_EOT_PACKET means that EoT packets will actually > > > be disabled. Fix this by including _NO_ in the flag names, e.g. > > > MIPI_DSI_MODE_NO_EOT_PACKET. > > > > > > Signed-off-by: Nicolas Boichat > > > > Hi Nicolas, > > > > in this thread: > > https://lore.kernel.org/dri-devel/2021023309.1.I629b2366a6591410359c7fcf6d385b474b705ca2@changeid/ > > I see that several people added their Reviewed-by. > > > > Please either add the tgas if missing, or elaborate why you left them out. > > Oh simple, I just forgot. Yeah, know that feeling. > > I regenerated the patch so it's a bit different from v1... Not 100% > sure if I can add those, since those were for the overall patch: > Reviewed-by: Robert Foss > Reviewed-by: Laurent Pinchart > Reviewed-by: Andrzej Hajda . > > Those 2 shouldn't be a problem: > Reviewed-by: Xin Ji # anx7625.c > Reviewed-by: Abhinav Kumar # msm/dsi > > > I was suprised this had not landed yet. > > Yep. Let me know if you want me to send a v3 with those tags. Please resend a v3 with the tags. Sam
Re: [PATCH] fbcon: Out-Of-Bounds write in sys_imageblit, add range check
Hi, On Mon, Jul 26, 2021 at 11:32:37AM +, tcs_kernel(腾讯云内核开发者) wrote: > yres and vyres can be controlled by user mode paramaters, and cause p->vrows > to become a negative value. While this value be passed to real_y function, > the ypos will be out of screen range. > This is an out-of-bounds write bug. Please investigate if you can validate the user-supplied values for yres and vyres earlier so the code never reaches the below statements. This would also make it much more explicit what is going on. Sam > > > diff --git a/drivers/video/fbdev/core/fbcon.c > b/drivers/video/fbdev/core/fbcon.c > index 22bb3892f6bd..0970de46782f 100644 > --- a/drivers/video/fbdev/core/fbcon.c > +++ b/drivers/video/fbdev/core/fbcon.c > @@ -1956,11 +1956,12 @@ static void updatescrollmode(struct fbcon_display *p, > int yres = FBCON_SWAP(ops->rotate, info->var.yres, info->var.xres); > int vyres = FBCON_SWAP(ops->rotate, info->var.yres_virtual, >info->var.xres_virtual); > + int rows = vc->vc_rows; > > p->vrows = vyres/fh; > - if (yres > (fh * (vc->vc_rows + 1))) > - p->vrows -= (yres - (fh * vc->vc_rows)) / fh; > - if ((yres % fh) && (vyres % fh < yres % fh)) > + if ((yres > (fh * (rows + 1))) && (vyres >= (yres - (fh * rows))) && > p->vrows) > + p->vrows -= (yres - (fh * rows)) / fh; > + if ((yres % fh) && (vyres % fh < yres % fh) && p->vrows) > p->vrows--; > } >
Re: [Intel-gfx] [PATCH 02/30] drm/i915/display: split DISPLAY_VER 9 and 10 in intel_setup_outputs()
On Mon, Jul 26, 2021 at 06:20:03AM -0400, Rodrigo Vivi wrote: On Sat, Jul 24, 2021 at 10:02:15PM -0700, Lucas De Marchi wrote: On Sat, Jul 24, 2021 at 06:41:21PM +0100, Christoph Hellwig wrote: > Still tests fine: > > Tested-by: Christoph Hellwig I just pushed this to drm-intel-next as part of another series and added your Tested-by. Rodrigo, can you pick this up for -fixes? This should go with your other patch to fix the port mask, too. done. But while doing this and reviewing this series at the same time I got myself wondering if we shouldn't remove the PORT_F support entirely... well, there is still ICL with some skus having it. I'm not sure we actually have that sku out in the wild, but if we do, we wouldn't be able to remove it. Lucas De Marchi Thanks for the bug report and test. Lucas De Marchi ___ Intel-gfx mailing list intel-...@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[PATCH 0/2] drm/msm: Reduce fence signal latency
From: Rob Clark A couple tweaks to reduce fence signal latency. Rob Clark (2): drm/msm: Let fences read directly from memptrs drm/msm: Signal fences sooner drivers/gpu/drm/msm/msm_fence.c | 11 +-- drivers/gpu/drm/msm/msm_fence.h | 41 +++--- drivers/gpu/drm/msm/msm_gpu.c| 44 drivers/gpu/drm/msm/msm_ringbuffer.c | 2 +- 4 files changed, 73 insertions(+), 25 deletions(-) -- 2.31.1
[PATCH 1/2] drm/msm: Let fences read directly from memptrs
From: Rob Clark
Let dma_fence::signaled, etc, read directly from the address that the hw
is writing with updated completed fence seqno, so we can potentially
notice that the fence is signaled sooner.
Plus add some docs.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_fence.c | 11 ++--
drivers/gpu/drm/msm/msm_fence.h | 41 +---
drivers/gpu/drm/msm/msm_ringbuffer.c | 2 +-
3 files changed, 47 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_fence.c b/drivers/gpu/drm/msm/msm_fence.c
index cd59a5918038..b92a9091a1e2 100644
--- a/drivers/gpu/drm/msm/msm_fence.c
+++ b/drivers/gpu/drm/msm/msm_fence.c
@@ -11,7 +11,8 @@
struct msm_fence_context *
-msm_fence_context_alloc(struct drm_device *dev, const char *name)
+msm_fence_context_alloc(struct drm_device *dev, volatile uint32_t *fenceptr,
+ const char *name)
{
struct msm_fence_context *fctx;
@@ -22,6 +23,7 @@ msm_fence_context_alloc(struct drm_device *dev, const char
*name)
fctx->dev = dev;
strncpy(fctx->name, name, sizeof(fctx->name));
fctx->context = dma_fence_context_alloc(1);
+ fctx->fenceptr = fenceptr;
init_waitqueue_head(&fctx->event);
spin_lock_init(&fctx->spinlock);
@@ -35,7 +37,12 @@ void msm_fence_context_free(struct msm_fence_context *fctx)
static inline bool fence_completed(struct msm_fence_context *fctx, uint32_t
fence)
{
- return (int32_t)(fctx->completed_fence - fence) >= 0;
+ /*
+* Note: Check completed_fence first, as fenceptr is in a write-combine
+* mapping, so it will be more expensive to read.
+*/
+ return (int32_t)(fctx->completed_fence - fence) >= 0 ||
+ (int32_t)(*fctx->fenceptr - fence) >= 0;
}
/* legacy path for WAIT_FENCE ioctl: */
diff --git a/drivers/gpu/drm/msm/msm_fence.h b/drivers/gpu/drm/msm/msm_fence.h
index 2d9af66dcca5..6ab97062ff1a 100644
--- a/drivers/gpu/drm/msm/msm_fence.h
+++ b/drivers/gpu/drm/msm/msm_fence.h
@@ -9,19 +9,52 @@
#include "msm_drv.h"
+/**
+ * struct msm_fence_context - fence context for gpu
+ *
+ * Each ringbuffer has a single fence context, with the GPU writing an
+ * incrementing fence seqno at the end of each submit
+ */
struct msm_fence_context {
struct drm_device *dev;
+ /** name: human readable name for fence timeline */
char name[32];
+ /** context: see dma_fence_context_alloc() */
unsigned context;
- /* last_fence == completed_fence --> no pending work */
- uint32_t last_fence; /* last assigned fence */
- uint32_t completed_fence; /* last completed fence */
+
+ /**
+* last_fence:
+*
+* Last assigned fence, incremented each time a fence is created
+* on this fence context. If last_fence == completed_fence,
+* there is no remaining pending work
+*/
+ uint32_t last_fence;
+
+ /**
+* completed_fence:
+*
+* The last completed fence, updated from the CPU after interrupt
+* from GPU
+*/
+ uint32_t completed_fence;
+
+ /**
+* fenceptr:
+*
+* The address that the GPU directly writes with completed fence
+* seqno. This can be ahead of completed_fence. We can peek at
+* this to see if a fence has already signaled but the CPU hasn't
+* gotten around to handling the irq and updating completed_fence
+*/
+ volatile uint32_t *fenceptr;
+
wait_queue_head_t event;
spinlock_t spinlock;
};
struct msm_fence_context * msm_fence_context_alloc(struct drm_device *dev,
- const char *name);
+ volatile uint32_t *fenceptr, const char *name);
void msm_fence_context_free(struct msm_fence_context *fctx);
int msm_wait_fence(struct msm_fence_context *fctx, uint32_t fence,
diff --git a/drivers/gpu/drm/msm/msm_ringbuffer.c
b/drivers/gpu/drm/msm/msm_ringbuffer.c
index 4d2a2a4abef8..7e92d9532454 100644
--- a/drivers/gpu/drm/msm/msm_ringbuffer.c
+++ b/drivers/gpu/drm/msm/msm_ringbuffer.c
@@ -51,7 +51,7 @@ struct msm_ringbuffer *msm_ringbuffer_new(struct msm_gpu
*gpu, int id,
snprintf(name, sizeof(name), "gpu-ring-%d", ring->id);
- ring->fctx = msm_fence_context_alloc(gpu->dev, name);
+ ring->fctx = msm_fence_context_alloc(gpu->dev, &ring->memptrs->fence,
name);
return ring;
--
2.31.1
[PATCH 2/2] drm/msm: Signal fences sooner
From: Rob Clark
Nothing we do to in update_fences() can't be done in an atomic context,
so move this into the GPU's irq context to reduce latency (and call
dma_fence_signal() so we aren't relying on dma_fence_is_signaled() which
would defeat the purpose).
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gpu.c | 44 +--
1 file changed, 26 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
index 0ebf7bc6ad09..647af45cf892 100644
--- a/drivers/gpu/drm/msm/msm_gpu.c
+++ b/drivers/gpu/drm/msm/msm_gpu.c
@@ -278,16 +278,18 @@ static void update_fences(struct msm_gpu *gpu, struct
msm_ringbuffer *ring,
uint32_t fence)
{
struct msm_gem_submit *submit;
+ unsigned long flags;
- spin_lock(&ring->submit_lock);
+ spin_lock_irqsave(&ring->submit_lock, flags);
list_for_each_entry(submit, &ring->submits, node) {
if (submit->seqno > fence)
break;
msm_update_fence(submit->ring->fctx,
submit->fence->seqno);
+ dma_fence_signal(submit->fence);
}
- spin_unlock(&ring->submit_lock);
+ spin_unlock_irqrestore(&ring->submit_lock, flags);
}
#ifdef CONFIG_DEV_COREDUMP
@@ -443,15 +445,16 @@ static struct msm_gem_submit *
find_submit(struct msm_ringbuffer *ring, uint32_t fence)
{
struct msm_gem_submit *submit;
+ unsigned long flags;
- spin_lock(&ring->submit_lock);
+ spin_lock_irqsave(&ring->submit_lock, flags);
list_for_each_entry(submit, &ring->submits, node) {
if (submit->seqno == fence) {
- spin_unlock(&ring->submit_lock);
+ spin_unlock_irqrestore(&ring->submit_lock, flags);
return submit;
}
}
- spin_unlock(&ring->submit_lock);
+ spin_unlock_irqrestore(&ring->submit_lock, flags);
return NULL;
}
@@ -547,11 +550,12 @@ static void recover_worker(struct kthread_work *work)
*/
for (i = 0; i < gpu->nr_rings; i++) {
struct msm_ringbuffer *ring = gpu->rb[i];
+ unsigned long flags;
- spin_lock(&ring->submit_lock);
+ spin_lock_irqsave(&ring->submit_lock, flags);
list_for_each_entry(submit, &ring->submits, node)
gpu->funcs->submit(gpu, submit);
- spin_unlock(&ring->submit_lock);
+ spin_unlock_irqrestore(&ring->submit_lock, flags);
}
}
@@ -641,7 +645,7 @@ static void hangcheck_handler(struct timer_list *t)
hangcheck_timer_reset(gpu);
/* workaround for missing irq: */
- kthread_queue_work(gpu->worker, &gpu->retire_work);
+ msm_gpu_retire(gpu);
}
/*
@@ -752,6 +756,7 @@ static void retire_submit(struct msm_gpu *gpu, struct
msm_ringbuffer *ring,
int index = submit->seqno % MSM_GPU_SUBMIT_STATS_COUNT;
volatile struct msm_gpu_submit_stats *stats;
u64 elapsed, clock = 0;
+ unsigned long flags;
int i;
stats = &ring->memptrs->stats[index];
@@ -781,9 +786,9 @@ static void retire_submit(struct msm_gpu *gpu, struct
msm_ringbuffer *ring,
pm_runtime_mark_last_busy(&gpu->pdev->dev);
pm_runtime_put_autosuspend(&gpu->pdev->dev);
- spin_lock(&ring->submit_lock);
+ spin_lock_irqsave(&ring->submit_lock, flags);
list_del(&submit->node);
- spin_unlock(&ring->submit_lock);
+ spin_unlock_irqrestore(&ring->submit_lock, flags);
msm_gem_submit_put(submit);
}
@@ -798,11 +803,12 @@ static void retire_submits(struct msm_gpu *gpu)
while (true) {
struct msm_gem_submit *submit = NULL;
+ unsigned long flags;
- spin_lock(&ring->submit_lock);
+ spin_lock_irqsave(&ring->submit_lock, flags);
submit = list_first_entry_or_null(&ring->submits,
struct msm_gem_submit, node);
- spin_unlock(&ring->submit_lock);
+ spin_unlock_irqrestore(&ring->submit_lock, flags);
/*
* If no submit, we are done. If submit->fence hasn't
@@ -821,10 +827,6 @@ static void retire_submits(struct msm_gpu *gpu)
static void retire_worker(struct kthread_work *work)
{
struct msm_gpu *gpu = container_of(work, struct msm_gpu, retire_work);
- int i;
-
- for (i = 0; i < gpu->nr_rings; i++)
- update_fences(gpu, gpu->rb[i], gpu->rb[i]->memptrs->fence);
retire_submits(gpu);
}
@@ -832,6 +834,11 @@ static void retire_worker(struct kthread_work *work)
/* call from irq handler to schedule w
[PATCH v2 0/3] drm/msm: Improved devfreq tuning
From: Rob Clark This is the outcome of trying to fix some bad gpu freq behavior seen in some use-cases, in particular mobile games that throttle themselves to 30fps. With the existing tuning, we'd end up spending most of the time that we should be running fast at a low freq, and most of the idle time at a high freq. First two patches are prep, 3/3 is the interesting bit. See the patch description in 3/3 for more details. v2: struct_mutex serializes the submit path, but not the retire path, so add a dedicated lock to serialize active<->idle transitions. Rob Clark (3): drm/msm: Split out devfreq handling drm/msm: Split out get_freq() helper drm/msm: Devfreq tuning drivers/gpu/drm/msm/Makefile | 1 + drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 4 +- drivers/gpu/drm/msm/msm_gpu.c | 132 +++-- drivers/gpu/drm/msm/msm_gpu.h | 61 +++- drivers/gpu/drm/msm/msm_gpu_devfreq.c | 203 ++ 5 files changed, 280 insertions(+), 121 deletions(-) create mode 100644 drivers/gpu/drm/msm/msm_gpu_devfreq.c -- 2.31.1
[PATCH v2 1/3] drm/msm: Split out devfreq handling
From: Rob Clark
Before we start adding more cleverness, split it into it's own file.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/Makefile | 1 +
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 4 +-
drivers/gpu/drm/msm/msm_gpu.c | 116 +-
drivers/gpu/drm/msm/msm_gpu.h | 32 +--
drivers/gpu/drm/msm/msm_gpu_devfreq.c | 133 ++
5 files changed, 165 insertions(+), 121 deletions(-)
create mode 100644 drivers/gpu/drm/msm/msm_gpu_devfreq.c
diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index 2c00aa70b708..904535eda0c4 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -90,6 +90,7 @@ msm-y := \
msm_gem_submit.o \
msm_gem_vma.o \
msm_gpu.o \
+ msm_gpu_devfreq.o \
msm_iommu.o \
msm_perf.o \
msm_rd.o \
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index 9db9f7847ea8..91f637b908f4 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -1477,7 +1477,7 @@ static int a6xx_pm_resume(struct msm_gpu *gpu)
if (ret)
return ret;
- msm_gpu_resume_devfreq(gpu);
+ msm_devfreq_resume(gpu);
a6xx_llc_activate(a6xx_gpu);
@@ -1494,7 +1494,7 @@ static int a6xx_pm_suspend(struct msm_gpu *gpu)
a6xx_llc_deactivate(a6xx_gpu);
- devfreq_suspend_device(gpu->devfreq.devfreq);
+ msm_devfreq_suspend(gpu);
ret = a6xx_gmu_stop(a6xx_gpu);
if (ret)
diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
index 647af45cf892..fedbd785e42f 100644
--- a/drivers/gpu/drm/msm/msm_gpu.c
+++ b/drivers/gpu/drm/msm/msm_gpu.c
@@ -13,8 +13,6 @@
#include
#include
-#include
-#include
#include
#include
@@ -22,106 +20,6 @@
* Power Management:
*/
-static int msm_devfreq_target(struct device *dev, unsigned long *freq,
- u32 flags)
-{
- struct msm_gpu *gpu = dev_to_gpu(dev);
- struct dev_pm_opp *opp;
-
- opp = devfreq_recommended_opp(dev, freq, flags);
-
- if (IS_ERR(opp))
- return PTR_ERR(opp);
-
- trace_msm_gpu_freq_change(dev_pm_opp_get_freq(opp));
-
- if (gpu->funcs->gpu_set_freq)
- gpu->funcs->gpu_set_freq(gpu, opp);
- else
- clk_set_rate(gpu->core_clk, *freq);
-
- dev_pm_opp_put(opp);
-
- return 0;
-}
-
-static int msm_devfreq_get_dev_status(struct device *dev,
- struct devfreq_dev_status *status)
-{
- struct msm_gpu *gpu = dev_to_gpu(dev);
- ktime_t time;
-
- if (gpu->funcs->gpu_get_freq)
- status->current_frequency = gpu->funcs->gpu_get_freq(gpu);
- else
- status->current_frequency = clk_get_rate(gpu->core_clk);
-
- status->busy_time = gpu->funcs->gpu_busy(gpu);
-
- time = ktime_get();
- status->total_time = ktime_us_delta(time, gpu->devfreq.time);
- gpu->devfreq.time = time;
-
- return 0;
-}
-
-static int msm_devfreq_get_cur_freq(struct device *dev, unsigned long *freq)
-{
- struct msm_gpu *gpu = dev_to_gpu(dev);
-
- if (gpu->funcs->gpu_get_freq)
- *freq = gpu->funcs->gpu_get_freq(gpu);
- else
- *freq = clk_get_rate(gpu->core_clk);
-
- return 0;
-}
-
-static struct devfreq_dev_profile msm_devfreq_profile = {
- .polling_ms = 10,
- .target = msm_devfreq_target,
- .get_dev_status = msm_devfreq_get_dev_status,
- .get_cur_freq = msm_devfreq_get_cur_freq,
-};
-
-static void msm_devfreq_init(struct msm_gpu *gpu)
-{
- /* We need target support to do devfreq */
- if (!gpu->funcs->gpu_busy)
- return;
-
- msm_devfreq_profile.initial_freq = gpu->fast_rate;
-
- /*
-* Don't set the freq_table or max_state and let devfreq build the table
-* from OPP
-* After a deferred probe, these may have be left to non-zero values,
-* so set them back to zero before creating the devfreq device
-*/
- msm_devfreq_profile.freq_table = NULL;
- msm_devfreq_profile.max_state = 0;
-
- gpu->devfreq.devfreq = devm_devfreq_add_device(&gpu->pdev->dev,
- &msm_devfreq_profile, DEVFREQ_GOV_SIMPLE_ONDEMAND,
- NULL);
-
- if (IS_ERR(gpu->devfreq.devfreq)) {
- DRM_DEV_ERROR(&gpu->pdev->dev, "Couldn't initialize GPU
devfreq\n");
- gpu->devfreq.devfreq = NULL;
- return;
- }
-
- devfreq_suspend_device(gpu->devfreq.devfreq);
-
- gpu->cooling = of_devfreq_cooling_register(gpu->pdev->dev.of_node,
- gpu->devfreq.devfreq);
- if (IS_ERR(gpu->cooling)) {
- DRM_DEV_ERROR(&gpu->pdev->dev,
- "Couldn't register GPU cooling device\n");
- gpu->cooling = N
[PATCH v2 2/3] drm/msm: Split out get_freq() helper
From: Rob Clark
In the next patch, it grows a bit more, so lets not duplicate the logic
in multiple places.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gpu_devfreq.c | 21 ++---
1 file changed, 10 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gpu_devfreq.c
b/drivers/gpu/drm/msm/msm_gpu_devfreq.c
index 3bcea0baddab..2e24a97be624 100644
--- a/drivers/gpu/drm/msm/msm_gpu_devfreq.c
+++ b/drivers/gpu/drm/msm/msm_gpu_devfreq.c
@@ -37,17 +37,21 @@ static int msm_devfreq_target(struct device *dev, unsigned
long *freq,
return 0;
}
+static unsigned long get_freq(struct msm_gpu *gpu)
+{
+ if (gpu->funcs->gpu_get_freq)
+ return gpu->funcs->gpu_get_freq(gpu);
+
+ return clk_get_rate(gpu->core_clk);
+}
+
static int msm_devfreq_get_dev_status(struct device *dev,
struct devfreq_dev_status *status)
{
struct msm_gpu *gpu = dev_to_gpu(dev);
ktime_t time;
- if (gpu->funcs->gpu_get_freq)
- status->current_frequency = gpu->funcs->gpu_get_freq(gpu);
- else
- status->current_frequency = clk_get_rate(gpu->core_clk);
-
+ status->current_frequency = get_freq(gpu);
status->busy_time = gpu->funcs->gpu_busy(gpu);
time = ktime_get();
@@ -59,12 +63,7 @@ static int msm_devfreq_get_dev_status(struct device *dev,
static int msm_devfreq_get_cur_freq(struct device *dev, unsigned long *freq)
{
- struct msm_gpu *gpu = dev_to_gpu(dev);
-
- if (gpu->funcs->gpu_get_freq)
- *freq = gpu->funcs->gpu_get_freq(gpu);
- else
- *freq = clk_get_rate(gpu->core_clk);
+ *freq = get_freq(dev_to_gpu(dev));
return 0;
}
--
2.31.1
[PATCH v2 3/3] drm/msm: Devfreq tuning
From: Rob Clark
This adds a few things to try and make frequency scaling better match
the workload:
1) Longer polling interval to avoid whip-lashing between too-high and
too-low frequencies in certain workloads, like mobile games which
throttle themselves to 30fps.
Previously our polling interval was short enough to let things
ramp down to minimum freq in the "off" frame, but long enough to
not react quickly enough when rendering started on the next frame,
leading to uneven frame times. (Ie. rather than a consistent 33ms
it would alternate between 16/33/48ms.)
2) Awareness of when the GPU is active vs idle. Since we know when
the GPU is active vs idle, we can clamp the frequency down to the
minimum while it is idle. (If it is idle for long enough, then
the autosuspend delay will eventually kick in and power down the
GPU.)
Since devfreq has no knowledge of powered-but-idle, this takes a
small bit of trickery to maintain a "fake" frequency while idle.
This, combined with the longer polling period allows devfreq to
arrive at a reasonable "active" frequency, while still clamping
to minimum freq when idle to reduce power draw.
3) Boost. Because simple_ondemand needs to see a certain threshold
of busyness to ramp up, we could end up needing multiple polling
cycles before it reacts appropriately on interactive workloads
(ex. scrolling a web page after reading for some time), on top
of the already lengthened polling interval, when we see a idle
to active transition after a period of idle time we boost the
frequency that we return to.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gpu.c | 16 ++
drivers/gpu/drm/msm/msm_gpu.h | 29 +++
drivers/gpu/drm/msm/msm_gpu_devfreq.c | 73 ++-
3 files changed, 117 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
index fedbd785e42f..c4ed8694f721 100644
--- a/drivers/gpu/drm/msm/msm_gpu.c
+++ b/drivers/gpu/drm/msm/msm_gpu.c
@@ -680,6 +680,14 @@ static void retire_submit(struct msm_gpu *gpu, struct
msm_ringbuffer *ring,
list_del(&submit->node);
spin_unlock_irqrestore(&ring->submit_lock, flags);
+ /* Update devfreq on transition from active->idle: */
+ mutex_lock(&gpu->active_lock);
+ gpu->active_submits--;
+ WARN_ON(gpu->active_submits < 0);
+ if (!gpu->active_submits)
+ msm_devfreq_idle(gpu);
+ mutex_unlock(&gpu->active_lock);
+
msm_gem_submit_put(submit);
}
@@ -781,6 +789,13 @@ void msm_gpu_submit(struct msm_gpu *gpu, struct
msm_gem_submit *submit)
list_add_tail(&submit->node, &ring->submits);
spin_unlock_irqrestore(&ring->submit_lock, flags);
+ /* Update devfreq on transition from idle->active: */
+ mutex_lock(&gpu->active_lock);
+ if (!gpu->active_submits)
+ msm_devfreq_active(gpu);
+ gpu->active_submits++;
+ mutex_unlock(&gpu->active_lock);
+
gpu->funcs->submit(gpu, submit);
priv->lastctx = submit->queue->ctx;
@@ -866,6 +881,7 @@ int msm_gpu_init(struct drm_device *drm, struct
platform_device *pdev,
sched_set_fifo_low(gpu->worker->task);
INIT_LIST_HEAD(&gpu->active_list);
+ mutex_init(&gpu->active_lock);
kthread_init_work(&gpu->retire_work, retire_worker);
kthread_init_work(&gpu->recover_work, recover_worker);
kthread_init_work(&gpu->fault_work, fault_worker);
diff --git a/drivers/gpu/drm/msm/msm_gpu.h b/drivers/gpu/drm/msm/msm_gpu.h
index 2e61d05293e6..710c3fedfbf3 100644
--- a/drivers/gpu/drm/msm/msm_gpu.h
+++ b/drivers/gpu/drm/msm/msm_gpu.h
@@ -98,6 +98,20 @@ struct msm_gpu_devfreq {
/** time: Time of last sampling period. */
ktime_t time;
+
+ /** idle_time: Time of last transition to idle: */
+ ktime_t idle_time;
+
+ /**
+* idle_freq:
+*
+* Shadow frequency used while the GPU is idle. From the PoV of
+* the devfreq governor, we are continuing to sample busyness and
+* adjust frequency while the GPU is idle, but we use this shadow
+* value as the GPU is actually clamped to minimum frequency while
+* it is inactive.
+*/
+ unsigned long idle_freq;
};
struct msm_gpu {
@@ -129,6 +143,19 @@ struct msm_gpu {
*/
struct list_head active_list;
+ /**
+* active_submits:
+*
+* The number of submitted but not yet retired submits, used to
+* determine transitions between active and idle.
+*
+* Protected by lock
+*/
+ int active_submits;
+
+ /** lock: protects active_submits and idle/active transitions */
+ struct mutex active_lock;
+
/* does gpu need hw_init? */
bool needs_hw_init;
@@ -322,6 +349,8 @@ void msm_devfreq_init(struct msm_gpu *gpu);
void msm_devfreq_cle
[PATCH v2 00/12] drm/msm: drm scheduler conversion and cleanups
From: Rob Clark
Conversion to gpu_scheduler, and bonus removal of
drm_gem_object_put_locked()
v2: Fix priority mixup (msm UAPI has lower numeric priority value as
higher priority, inverse of drm/scheduler) and add some comments
in the UAPI header to clarify.
Now that we move active refcnt get into msm_gem_submit, add a
patch to mark all bos busy before pinning, to avoid evicting bos
used in same batch.
Fix bo locking for cmdstream dumping ($debugfs/n/{rd,hangrd})
Rob Clark (12):
drm/msm: Docs and misc cleanup
drm/msm: Small submitqueue creation cleanup
drm/msm: drop drm_gem_object_put_locked()
drm: Drop drm_gem_object_put_locked()
drm/msm/submit: Simplify out-fence-fd handling
drm/msm: Consolidate submit bo state
drm/msm: Track "seqno" fences by idr
drm/msm: Return ERR_PTR() from submit_create()
drm/msm: Conversion to drm scheduler
drm/msm: Drop struct_mutex in submit path
drm/msm: Utilize gpu scheduler priorities
drm/msm/gem: Mark active before pinning
drivers/gpu/drm/drm_gem.c | 22 --
drivers/gpu/drm/msm/Kconfig | 1 +
drivers/gpu/drm/msm/adreno/a5xx_debugfs.c | 4 +-
drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 6 +-
drivers/gpu/drm/msm/adreno/a5xx_power.c | 2 +-
drivers/gpu/drm/msm/adreno/a5xx_preempt.c | 7 +-
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 12 +-
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 2 +-
drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c | 4 +-
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 6 +-
drivers/gpu/drm/msm/msm_drv.c | 30 +-
drivers/gpu/drm/msm/msm_fence.c | 39 ---
drivers/gpu/drm/msm/msm_fence.h | 2 -
drivers/gpu/drm/msm/msm_gem.c | 93 +-
drivers/gpu/drm/msm/msm_gem.h | 39 ++-
drivers/gpu/drm/msm/msm_gem_submit.c| 316
drivers/gpu/drm/msm/msm_gpu.c | 46 +--
drivers/gpu/drm/msm/msm_gpu.h | 78 -
drivers/gpu/drm/msm/msm_rd.c| 6 +-
drivers/gpu/drm/msm/msm_ringbuffer.c| 70 -
drivers/gpu/drm/msm/msm_ringbuffer.h| 12 +
drivers/gpu/drm/msm/msm_submitqueue.c | 53 +++-
include/drm/drm_gem.h | 2 -
include/uapi/drm/msm_drm.h | 14 +-
24 files changed, 503 insertions(+), 363 deletions(-)
--
2.31.1
[PATCH v2 01/12] drm/msm: Docs and misc cleanup
From: Rob Clark
Fix a couple incorrect or misspelt comments, and add submitqueue doc
comment.
Signed-off-by: Rob Clark
Acked-by: Christian König
---
drivers/gpu/drm/msm/msm_gem.h | 3 +--
drivers/gpu/drm/msm/msm_gem_submit.c | 1 +
drivers/gpu/drm/msm/msm_gpu.h | 15 +++
drivers/gpu/drm/msm/msm_ringbuffer.c | 2 +-
drivers/gpu/drm/msm/msm_submitqueue.c | 9 +
5 files changed, 23 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gem.h b/drivers/gpu/drm/msm/msm_gem.h
index 405f8411e395..d69fcb37ce17 100644
--- a/drivers/gpu/drm/msm/msm_gem.h
+++ b/drivers/gpu/drm/msm/msm_gem.h
@@ -313,8 +313,7 @@ void msm_gem_vunmap(struct drm_gem_object *obj);
/* Created per submit-ioctl, to track bo's and cmdstream bufs, etc,
* associated with the cmdstream submission for synchronization (and
- * make it easier to unwind when things go wrong, etc). This only
- * lasts for the duration of the submit-ioctl.
+ * make it easier to unwind when things go wrong, etc).
*/
struct msm_gem_submit {
struct kref ref;
diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c
b/drivers/gpu/drm/msm/msm_gem_submit.c
index 44f84bfd0c0e..6d46f9275a40 100644
--- a/drivers/gpu/drm/msm/msm_gem_submit.c
+++ b/drivers/gpu/drm/msm/msm_gem_submit.c
@@ -655,6 +655,7 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void *data,
bool has_ww_ticket = false;
unsigned i;
int ret, submitid;
+
if (!gpu)
return -ENXIO;
diff --git a/drivers/gpu/drm/msm/msm_gpu.h b/drivers/gpu/drm/msm/msm_gpu.h
index 710c3fedfbf3..96efcb31e502 100644
--- a/drivers/gpu/drm/msm/msm_gpu.h
+++ b/drivers/gpu/drm/msm/msm_gpu.h
@@ -250,6 +250,21 @@ struct msm_gpu_perfcntr {
const char *name;
};
+/**
+ * A submitqueue is associated with a gl context or vk queue (or equiv)
+ * in userspace.
+ *
+ * @id:userspace id for the submitqueue, unique within the drm_file
+ * @flags: userspace flags for the submitqueue, specified at creation
+ * (currently unusued)
+ * @prio: the submitqueue priority
+ * @faults:the number of GPU hangs associated with this submitqueue
+ * @ctx: the per-drm_file context associated with the submitqueue (ie.
+ * which set of pgtables do submits jobs associated with the
+ * submitqueue use)
+ * @node: node in the context's list of submitqueues
+ * @ref: reference count
+ */
struct msm_gpu_submitqueue {
int id;
u32 flags;
diff --git a/drivers/gpu/drm/msm/msm_ringbuffer.c
b/drivers/gpu/drm/msm/msm_ringbuffer.c
index 7e92d9532454..054461662af5 100644
--- a/drivers/gpu/drm/msm/msm_ringbuffer.c
+++ b/drivers/gpu/drm/msm/msm_ringbuffer.c
@@ -32,7 +32,7 @@ struct msm_ringbuffer *msm_ringbuffer_new(struct msm_gpu
*gpu, int id,
if (IS_ERR(ring->start)) {
ret = PTR_ERR(ring->start);
- ring->start = 0;
+ ring->start = NULL;
goto fail;
}
diff --git a/drivers/gpu/drm/msm/msm_submitqueue.c
b/drivers/gpu/drm/msm/msm_submitqueue.c
index c3d206105d28..e5eef11ed014 100644
--- a/drivers/gpu/drm/msm/msm_submitqueue.c
+++ b/drivers/gpu/drm/msm/msm_submitqueue.c
@@ -98,17 +98,18 @@ int msm_submitqueue_create(struct drm_device *drm, struct
msm_file_private *ctx,
return 0;
}
+/*
+ * Create the default submit-queue (id==0), used for backwards compatibility
+ * for userspace that pre-dates the introduction of submitqueues.
+ */
int msm_submitqueue_init(struct drm_device *drm, struct msm_file_private *ctx)
{
struct msm_drm_private *priv = drm->dev_private;
int default_prio;
- if (!ctx)
- return 0;
-
/*
* Select priority 2 as the "default priority" unless nr_rings is less
-* than 2 and then pick the lowest pirority
+* than 2 and then pick the lowest priority
*/
default_prio = priv->gpu ?
clamp_t(uint32_t, 2, 0, priv->gpu->nr_rings - 1) : 0;
--
2.31.1
[PATCH v2 02/12] drm/msm: Small submitqueue creation cleanup
From: Rob Clark
If we don't have a gpu, there is no need to create a submitqueue, which
lets us simplify the error handling and submitqueue creation.
Signed-off-by: Rob Clark
Acked-by: Christian König
---
drivers/gpu/drm/msm/msm_submitqueue.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_submitqueue.c
b/drivers/gpu/drm/msm/msm_submitqueue.c
index e5eef11ed014..9e9fec61d629 100644
--- a/drivers/gpu/drm/msm/msm_submitqueue.c
+++ b/drivers/gpu/drm/msm/msm_submitqueue.c
@@ -66,6 +66,12 @@ int msm_submitqueue_create(struct drm_device *drm, struct
msm_file_private *ctx,
if (!ctx)
return -ENODEV;
+ if (!priv->gpu)
+ return -ENODEV;
+
+ if (prio >= priv->gpu->nr_rings)
+ return -EINVAL;
+
queue = kzalloc(sizeof(*queue), GFP_KERNEL);
if (!queue)
@@ -73,15 +79,7 @@ int msm_submitqueue_create(struct drm_device *drm, struct
msm_file_private *ctx,
kref_init(&queue->ref);
queue->flags = flags;
-
- if (priv->gpu) {
- if (prio >= priv->gpu->nr_rings) {
- kfree(queue);
- return -EINVAL;
- }
-
- queue->prio = prio;
- }
+ queue->prio = prio;
write_lock(&ctx->queuelock);
@@ -107,12 +105,14 @@ int msm_submitqueue_init(struct drm_device *drm, struct
msm_file_private *ctx)
struct msm_drm_private *priv = drm->dev_private;
int default_prio;
+ if (!priv->gpu)
+ return -ENODEV;
+
/*
* Select priority 2 as the "default priority" unless nr_rings is less
* than 2 and then pick the lowest priority
*/
- default_prio = priv->gpu ?
- clamp_t(uint32_t, 2, 0, priv->gpu->nr_rings - 1) : 0;
+ default_prio = clamp_t(uint32_t, 2, 0, priv->gpu->nr_rings - 1);
INIT_LIST_HEAD(&ctx->submitqueues);
--
2.31.1
[PATCH v2 03/12] drm/msm: drop drm_gem_object_put_locked()
From: Rob Clark
No idea why we were still using this. It certainly hasn't been needed
for some time. So drop the pointless twin codepaths.
Signed-off-by: Rob Clark
Acked-by: Christian König
---
drivers/gpu/drm/msm/adreno/a5xx_debugfs.c | 4 +-
drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 6 +--
drivers/gpu/drm/msm/adreno/a5xx_power.c | 2 +-
drivers/gpu/drm/msm/adreno/a5xx_preempt.c | 7 ++-
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 12 ++---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 2 +-
drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c | 4 +-
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 2 +-
drivers/gpu/drm/msm/msm_gem.c | 56 -
drivers/gpu/drm/msm/msm_gem.h | 7 +--
drivers/gpu/drm/msm/msm_gem_submit.c| 2 +-
drivers/gpu/drm/msm/msm_gpu.c | 4 +-
drivers/gpu/drm/msm/msm_ringbuffer.c| 2 +-
13 files changed, 33 insertions(+), 77 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a5xx_debugfs.c
b/drivers/gpu/drm/msm/adreno/a5xx_debugfs.c
index fc2c905b6c9e..c9d11d57aed6 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_debugfs.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_debugfs.c
@@ -117,13 +117,13 @@ reset_set(void *data, u64 val)
if (a5xx_gpu->pm4_bo) {
msm_gem_unpin_iova(a5xx_gpu->pm4_bo, gpu->aspace);
- drm_gem_object_put_locked(a5xx_gpu->pm4_bo);
+ drm_gem_object_put(a5xx_gpu->pm4_bo);
a5xx_gpu->pm4_bo = NULL;
}
if (a5xx_gpu->pfp_bo) {
msm_gem_unpin_iova(a5xx_gpu->pfp_bo, gpu->aspace);
- drm_gem_object_put_locked(a5xx_gpu->pfp_bo);
+ drm_gem_object_put(a5xx_gpu->pfp_bo);
a5xx_gpu->pfp_bo = NULL;
}
diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
index 7a271de9a212..0a93ed1d6b06 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
@@ -1415,7 +1415,7 @@ struct a5xx_gpu_state {
static int a5xx_crashdumper_init(struct msm_gpu *gpu,
struct a5xx_crashdumper *dumper)
{
- dumper->ptr = msm_gem_kernel_new_locked(gpu->dev,
+ dumper->ptr = msm_gem_kernel_new(gpu->dev,
SZ_1M, MSM_BO_WC, gpu->aspace,
&dumper->bo, &dumper->iova);
@@ -1517,7 +1517,7 @@ static void a5xx_gpu_state_get_hlsq_regs(struct msm_gpu
*gpu,
if (a5xx_crashdumper_run(gpu, &dumper)) {
kfree(a5xx_state->hlsqregs);
- msm_gem_kernel_put(dumper.bo, gpu->aspace, true);
+ msm_gem_kernel_put(dumper.bo, gpu->aspace);
return;
}
@@ -1525,7 +1525,7 @@ static void a5xx_gpu_state_get_hlsq_regs(struct msm_gpu
*gpu,
memcpy(a5xx_state->hlsqregs, dumper.ptr + (256 * SZ_1K),
count * sizeof(u32));
- msm_gem_kernel_put(dumper.bo, gpu->aspace, true);
+ msm_gem_kernel_put(dumper.bo, gpu->aspace);
}
static struct msm_gpu_state *a5xx_gpu_state_get(struct msm_gpu *gpu)
diff --git a/drivers/gpu/drm/msm/adreno/a5xx_power.c
b/drivers/gpu/drm/msm/adreno/a5xx_power.c
index cdb165236a88..0e63a1429189 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_power.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_power.c
@@ -362,7 +362,7 @@ void a5xx_gpmu_ucode_init(struct msm_gpu *gpu)
*/
bosize = (cmds_size + (cmds_size / TYPE4_MAX_PAYLOAD) + 1) << 2;
- ptr = msm_gem_kernel_new_locked(drm, bosize,
+ ptr = msm_gem_kernel_new(drm, bosize,
MSM_BO_WC | MSM_BO_GPU_READONLY, gpu->aspace,
&a5xx_gpu->gpmu_bo, &a5xx_gpu->gpmu_iova);
if (IS_ERR(ptr))
diff --git a/drivers/gpu/drm/msm/adreno/a5xx_preempt.c
b/drivers/gpu/drm/msm/adreno/a5xx_preempt.c
index ee72510ff8ce..8abc9a2b114a 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_preempt.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_preempt.c
@@ -240,7 +240,7 @@ static int preempt_init_ring(struct a5xx_gpu *a5xx_gpu,
A5XX_PREEMPT_COUNTER_SIZE,
MSM_BO_WC, gpu->aspace, &counters_bo, &counters_iova);
if (IS_ERR(counters)) {
- msm_gem_kernel_put(bo, gpu->aspace, true);
+ msm_gem_kernel_put(bo, gpu->aspace);
return PTR_ERR(counters);
}
@@ -272,9 +272,8 @@ void a5xx_preempt_fini(struct msm_gpu *gpu)
int i;
for (i = 0; i < gpu->nr_rings; i++) {
- msm_gem_kernel_put(a5xx_gpu->preempt_bo[i], gpu->aspace, true);
- msm_gem_kernel_put(a5xx_gpu->preempt_counters_bo[i],
- gpu->aspace, true);
+ msm_gem_kernel_put(a5xx_gpu->preempt_bo[i], gpu->aspace);
+ msm_gem_kernel_put(a5xx_gpu->preempt_counters_bo[i],
gpu->aspace);
}
}
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
index b349692219b7..d7cec7f0dde0 100644
--- a/drivers/gpu/drm/msm/adreno/a
[PATCH v2 04/12] drm: Drop drm_gem_object_put_locked()
From: Rob Clark
Now that no one is using it, remove it.
Signed-off-by: Rob Clark
Acked-by: Christian König
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/drm_gem.c | 22 --
include/drm/drm_gem.h | 2 --
2 files changed, 24 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 9989425e9875..c8866788b761 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -974,28 +974,6 @@ drm_gem_object_free(struct kref *kref)
}
EXPORT_SYMBOL(drm_gem_object_free);
-/**
- * drm_gem_object_put_locked - release a GEM buffer object reference
- * @obj: GEM buffer object
- *
- * This releases a reference to @obj. Callers must hold the
- * &drm_device.struct_mutex lock when calling this function, even when the
- * driver doesn't use &drm_device.struct_mutex for anything.
- *
- * For drivers not encumbered with legacy locking use
- * drm_gem_object_put() instead.
- */
-void
-drm_gem_object_put_locked(struct drm_gem_object *obj)
-{
- if (obj) {
- WARN_ON(!mutex_is_locked(&obj->dev->struct_mutex));
-
- kref_put(&obj->refcount, drm_gem_object_free);
- }
-}
-EXPORT_SYMBOL(drm_gem_object_put_locked);
-
/**
* drm_gem_vm_open - vma->ops->open implementation for GEM
* @vma: VM area structure
diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
index 240049566592..35e7f44c2a75 100644
--- a/include/drm/drm_gem.h
+++ b/include/drm/drm_gem.h
@@ -384,8 +384,6 @@ drm_gem_object_put(struct drm_gem_object *obj)
__drm_gem_object_put(obj);
}
-void drm_gem_object_put_locked(struct drm_gem_object *obj);
-
int drm_gem_handle_create(struct drm_file *file_priv,
struct drm_gem_object *obj,
u32 *handlep);
--
2.31.1
[PATCH v2 06/12] drm/msm: Consolidate submit bo state
From: Rob Clark
Move all the locked/active/pinned state handling to msm_gem_submit.c.
In particular, for drm/scheduler, we'll need to do all this before
pushing the submit job to the scheduler. But while we're at it we can
get rid of the dupicate pin and refcnt.
Signed-off-by: Rob Clark
Acked-by: Christian König
---
drivers/gpu/drm/msm/msm_gem.h| 2 +
drivers/gpu/drm/msm/msm_gem_submit.c | 92 ++--
drivers/gpu/drm/msm/msm_gpu.c| 29 +
3 files changed, 75 insertions(+), 48 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gem.h b/drivers/gpu/drm/msm/msm_gem.h
index 71ccf87a646b..da3af702a6c8 100644
--- a/drivers/gpu/drm/msm/msm_gem.h
+++ b/drivers/gpu/drm/msm/msm_gem.h
@@ -361,6 +361,8 @@ static inline void msm_gem_submit_put(struct msm_gem_submit
*submit)
kref_put(&submit->ref, __msm_gem_submit_destroy);
}
+void msm_submit_retire(struct msm_gem_submit *submit);
+
/* helper to determine of a buffer in submit should be dumped, used for both
* devcoredump and debugfs cmdstream dumping:
*/
diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c
b/drivers/gpu/drm/msm/msm_gem_submit.c
index 8abd743adfb0..4f02fa3c78f9 100644
--- a/drivers/gpu/drm/msm/msm_gem_submit.c
+++ b/drivers/gpu/drm/msm/msm_gem_submit.c
@@ -23,8 +23,8 @@
/* make sure these don't conflict w/ MSM_SUBMIT_BO_x */
#define BO_VALID0x8000 /* is current addr in cmdstream correct/valid? */
-#define BO_LOCKED 0x4000
-#define BO_PINNED 0x2000
+#define BO_LOCKED 0x4000 /* obj lock is held */
+#define BO_PINNED 0x2000 /* obj is pinned and on active list */
static struct msm_gem_submit *submit_create(struct drm_device *dev,
struct msm_gpu *gpu,
@@ -220,21 +220,33 @@ static int submit_lookup_cmds(struct msm_gem_submit
*submit,
return ret;
}
-static void submit_unlock_unpin_bo(struct msm_gem_submit *submit,
- int i, bool backoff)
+/* Unwind bo state, according to cleanup_flags. In the success case, only
+ * the lock is dropped at the end of the submit (and active/pin ref is dropped
+ * later when the submit is retired).
+ */
+static void submit_cleanup_bo(struct msm_gem_submit *submit, int i,
+ unsigned cleanup_flags)
{
- struct msm_gem_object *msm_obj = submit->bos[i].obj;
+ struct drm_gem_object *obj = &submit->bos[i].obj->base;
+ unsigned flags = submit->bos[i].flags & cleanup_flags;
- if (submit->bos[i].flags & BO_PINNED)
- msm_gem_unpin_iova_locked(&msm_obj->base, submit->aspace);
+ if (flags & BO_PINNED) {
+ msm_gem_unpin_iova_locked(obj, submit->aspace);
+ msm_gem_active_put(obj);
+ }
- if (submit->bos[i].flags & BO_LOCKED)
- dma_resv_unlock(msm_obj->base.resv);
+ if (flags & BO_LOCKED)
+ dma_resv_unlock(obj->resv);
- if (backoff && !(submit->bos[i].flags & BO_VALID))
- submit->bos[i].iova = 0;
+ submit->bos[i].flags &= ~cleanup_flags;
+}
- submit->bos[i].flags &= ~(BO_LOCKED | BO_PINNED);
+static void submit_unlock_unpin_bo(struct msm_gem_submit *submit, int i)
+{
+ submit_cleanup_bo(submit, i, BO_PINNED | BO_LOCKED);
+
+ if (!(submit->bos[i].flags & BO_VALID))
+ submit->bos[i].iova = 0;
}
/* This is where we make sure all the bo's are reserved and pin'd: */
@@ -266,10 +278,10 @@ static int submit_lock_objects(struct msm_gem_submit
*submit)
fail:
for (; i >= 0; i--)
- submit_unlock_unpin_bo(submit, i, true);
+ submit_unlock_unpin_bo(submit, i);
if (slow_locked > 0)
- submit_unlock_unpin_bo(submit, slow_locked, true);
+ submit_unlock_unpin_bo(submit, slow_locked);
if (ret == -EDEADLK) {
struct msm_gem_object *msm_obj = submit->bos[contended].obj;
@@ -325,16 +337,18 @@ static int submit_pin_objects(struct msm_gem_submit
*submit)
submit->valid = true;
for (i = 0; i < submit->nr_bos; i++) {
- struct msm_gem_object *msm_obj = submit->bos[i].obj;
+ struct drm_gem_object *obj = &submit->bos[i].obj->base;
uint64_t iova;
/* if locking succeeded, pin bo: */
- ret = msm_gem_get_and_pin_iova_locked(&msm_obj->base,
+ ret = msm_gem_get_and_pin_iova_locked(obj,
submit->aspace, &iova);
if (ret)
break;
+ msm_gem_active_get(obj, submit->gpu);
+
submit->bos[i].flags |= BO_PINNED;
if (iova == submit->bos[i].iova) {
@@ -350,6 +364,20 @@ static int submit_pin_objects(struct msm_gem_submit
*submit)
return ret;
}
+static void submit_attach_object_fences(struct msm_gem_submit *submit)
+{
+ int i;
+
+ for (i = 0; i < submit->nr_bos; i++) {
+ struct drm_gem_object *obj = &s
[PATCH v2 08/12] drm/msm: Return ERR_PTR() from submit_create()
From: Rob Clark
In the next patch, we start having more than a single potential failure
reason.
Signed-off-by: Rob Clark
Acked-by: Christian König
---
drivers/gpu/drm/msm/msm_gem_submit.c | 21 +
1 file changed, 9 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c
b/drivers/gpu/drm/msm/msm_gem_submit.c
index f6f595aae2c5..f570155bc086 100644
--- a/drivers/gpu/drm/msm/msm_gem_submit.c
+++ b/drivers/gpu/drm/msm/msm_gem_submit.c
@@ -32,30 +32,27 @@ static struct msm_gem_submit *submit_create(struct
drm_device *dev,
uint32_t nr_cmds)
{
struct msm_gem_submit *submit;
- uint64_t sz = struct_size(submit, bos, nr_bos) +
- ((u64)nr_cmds * sizeof(submit->cmd[0]));
+ uint64_t sz;
+
+ sz = struct_size(submit, bos, nr_bos) +
+ ((u64)nr_cmds * sizeof(submit->cmd[0]));
if (sz > SIZE_MAX)
- return NULL;
+ return ERR_PTR(-ENOMEM);
- submit = kmalloc(sz, GFP_KERNEL | __GFP_NOWARN | __GFP_NORETRY);
+ submit = kzalloc(sz, GFP_KERNEL | __GFP_NOWARN | __GFP_NORETRY);
if (!submit)
- return NULL;
+ return ERR_PTR(-ENOMEM);
kref_init(&submit->ref);
submit->dev = dev;
submit->aspace = queue->ctx->aspace;
submit->gpu = gpu;
- submit->fence = NULL;
submit->cmd = (void *)&submit->bos[nr_bos];
submit->queue = queue;
submit->ring = gpu->rb[queue->prio];
submit->fault_dumped = false;
- /* initially, until copy_from_user() and bo lookup succeeds: */
- submit->nr_bos = 0;
- submit->nr_cmds = 0;
-
INIT_LIST_HEAD(&submit->node);
INIT_LIST_HEAD(&submit->bo_list);
@@ -799,8 +796,8 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void *data,
submit = submit_create(dev, gpu, queue, args->nr_bos,
args->nr_cmds);
- if (!submit) {
- ret = -ENOMEM;
+ if (IS_ERR(submit)) {
+ ret = PTR_ERR(submit);
goto out_unlock;
}
--
2.31.1
[PATCH v2 05/12] drm/msm/submit: Simplify out-fence-fd handling
From: Rob Clark
No need for this to be split in two parts.
Signed-off-by: Rob Clark
Acked-by: Christian König
---
drivers/gpu/drm/msm/msm_gem_submit.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c
b/drivers/gpu/drm/msm/msm_gem_submit.c
index e789f68d5be1..8abd743adfb0 100644
--- a/drivers/gpu/drm/msm/msm_gem_submit.c
+++ b/drivers/gpu/drm/msm/msm_gem_submit.c
@@ -645,7 +645,6 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void *data,
struct msm_file_private *ctx = file->driver_priv;
struct msm_gem_submit *submit;
struct msm_gpu *gpu = priv->gpu;
- struct sync_file *sync_file = NULL;
struct msm_gpu_submitqueue *queue;
struct msm_ringbuffer *ring;
struct msm_submit_post_dep *post_deps = NULL;
@@ -824,22 +823,19 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void
*data,
}
if (args->flags & MSM_SUBMIT_FENCE_FD_OUT) {
- sync_file = sync_file_create(submit->fence);
+ struct sync_file *sync_file = sync_file_create(submit->fence);
if (!sync_file) {
ret = -ENOMEM;
goto out;
}
+ fd_install(out_fence_fd, sync_file->file);
+ args->fence_fd = out_fence_fd;
}
msm_gpu_submit(gpu, submit);
args->fence = submit->fence->seqno;
- if (args->flags & MSM_SUBMIT_FENCE_FD_OUT) {
- fd_install(out_fence_fd, sync_file->file);
- args->fence_fd = out_fence_fd;
- }
-
msm_reset_syncobjs(syncobjs_to_reset, args->nr_in_syncobjs);
msm_process_post_deps(post_deps, args->nr_out_syncobjs,
submit->fence);
--
2.31.1
[PATCH v2 09/12] drm/msm: Conversion to drm scheduler
From: Rob Clark
For existing adrenos, there is one or more ringbuffer, depending on
whether preemption is supported. When preemption is supported, each
ringbuffer has it's own priority. A submitqueue (which maps to a
gl context or vk queue in userspace) is mapped to a specific ring-
buffer at creation time, based on the submitqueue's priority.
Each ringbuffer has it's own drm_gpu_scheduler. Each submitqueue
maps to a drm_sched_entity. And each submit maps to a drm_sched_job.
Closes: https://gitlab.freedesktop.org/drm/msm/-/issues/4
Signed-off-by: Rob Clark
Acked-by: Christian König
---
drivers/gpu/drm/msm/Kconfig | 1 +
drivers/gpu/drm/msm/msm_gem.c | 35 --
drivers/gpu/drm/msm/msm_gem.h | 26 -
drivers/gpu/drm/msm/msm_gem_submit.c | 161 +-
drivers/gpu/drm/msm/msm_gpu.c | 13 +--
drivers/gpu/drm/msm/msm_gpu.h | 2 +
drivers/gpu/drm/msm/msm_rd.c | 6 +-
drivers/gpu/drm/msm/msm_ringbuffer.c | 66 +++
drivers/gpu/drm/msm/msm_ringbuffer.h | 12 ++
drivers/gpu/drm/msm/msm_submitqueue.c | 26 +
10 files changed, 217 insertions(+), 131 deletions(-)
diff --git a/drivers/gpu/drm/msm/Kconfig b/drivers/gpu/drm/msm/Kconfig
index 10f693ea89d3..896266267ad7 100644
--- a/drivers/gpu/drm/msm/Kconfig
+++ b/drivers/gpu/drm/msm/Kconfig
@@ -12,6 +12,7 @@ config DRM_MSM
select REGULATOR
select DRM_KMS_HELPER
select DRM_PANEL
+ select DRM_SCHED
select SHMEM
select TMPFS
select QCOM_SCM if ARCH_QCOM
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index 00a6289678dd..41a111c49cc7 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -806,41 +806,6 @@ void msm_gem_vunmap(struct drm_gem_object *obj)
msm_obj->vaddr = NULL;
}
-/* must be called before _move_to_active().. */
-int msm_gem_sync_object(struct drm_gem_object *obj,
- struct msm_fence_context *fctx, bool exclusive)
-{
- struct dma_resv_list *fobj;
- struct dma_fence *fence;
- int i, ret;
-
- fobj = dma_resv_get_list(obj->resv);
- if (!fobj || (fobj->shared_count == 0)) {
- fence = dma_resv_get_excl(obj->resv);
- /* don't need to wait on our own fences, since ring is fifo */
- if (fence && (fence->context != fctx->context)) {
- ret = dma_fence_wait(fence, true);
- if (ret)
- return ret;
- }
- }
-
- if (!exclusive || !fobj)
- return 0;
-
- for (i = 0; i < fobj->shared_count; i++) {
- fence = rcu_dereference_protected(fobj->shared[i],
- dma_resv_held(obj->resv));
- if (fence->context != fctx->context) {
- ret = dma_fence_wait(fence, true);
- if (ret)
- return ret;
- }
- }
-
- return 0;
-}
-
void msm_gem_active_get(struct drm_gem_object *obj, struct msm_gpu *gpu)
{
struct msm_gem_object *msm_obj = to_msm_bo(obj);
diff --git a/drivers/gpu/drm/msm/msm_gem.h b/drivers/gpu/drm/msm/msm_gem.h
index e0579abda5b9..a48114058ff9 100644
--- a/drivers/gpu/drm/msm/msm_gem.h
+++ b/drivers/gpu/drm/msm/msm_gem.h
@@ -9,6 +9,7 @@
#include
#include
+#include "drm/gpu_scheduler.h"
#include "msm_drv.h"
/* Make all GEM related WARN_ON()s ratelimited.. when things go wrong they
@@ -143,8 +144,6 @@ void *msm_gem_get_vaddr_active(struct drm_gem_object *obj);
void msm_gem_put_vaddr_locked(struct drm_gem_object *obj);
void msm_gem_put_vaddr(struct drm_gem_object *obj);
int msm_gem_madvise(struct drm_gem_object *obj, unsigned madv);
-int msm_gem_sync_object(struct drm_gem_object *obj,
- struct msm_fence_context *fctx, bool exclusive);
void msm_gem_active_get(struct drm_gem_object *obj, struct msm_gpu *gpu);
void msm_gem_active_put(struct drm_gem_object *obj);
int msm_gem_cpu_prep(struct drm_gem_object *obj, uint32_t op, ktime_t
*timeout);
@@ -311,6 +310,7 @@ void msm_gem_vunmap(struct drm_gem_object *obj);
* make it easier to unwind when things go wrong, etc).
*/
struct msm_gem_submit {
+ struct drm_sched_job base;
struct kref ref;
struct drm_device *dev;
struct msm_gpu *gpu;
@@ -319,7 +319,22 @@ struct msm_gem_submit {
struct list_head bo_list;
struct ww_acquire_ctx ticket;
uint32_t seqno; /* Sequence number of the submit on the ring */
- struct dma_fence *fence;
+
+ /* Array of struct dma_fence * to block on before submitting this job.
+*/
+ struct xarray deps;
+ unsigned long last_dep;
+
+ /* Hw fence, which is created when the scheduler executes the job, and
+* is signaled when the hw finishes (via seqno write from cmdstream)
+*/
+
[PATCH v2 10/12] drm/msm: Drop struct_mutex in submit path
From: Rob Clark
It is sufficient to serialize on the submit queue now.
Signed-off-by: Rob Clark
Acked-by: Christian König
---
drivers/gpu/drm/msm/msm_gem_submit.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c
b/drivers/gpu/drm/msm/msm_gem_submit.c
index 2b158433a6e5..affceccf145d 100644
--- a/drivers/gpu/drm/msm/msm_gem_submit.c
+++ b/drivers/gpu/drm/msm/msm_gem_submit.c
@@ -711,7 +711,7 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void *data,
struct msm_drm_private *priv = dev->dev_private;
struct drm_msm_gem_submit *args = data;
struct msm_file_private *ctx = file->driver_priv;
- struct msm_gem_submit *submit;
+ struct msm_gem_submit *submit = NULL;
struct msm_gpu *gpu = priv->gpu;
struct msm_gpu_submitqueue *queue;
struct msm_ringbuffer *ring;
@@ -755,7 +755,7 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void *data,
trace_msm_gpu_submit(pid_nr(pid), ring->id, submitid,
args->nr_bos, args->nr_cmds);
- ret = mutex_lock_interruptible(&dev->struct_mutex);
+ ret = mutex_lock_interruptible(&queue->lock);
if (ret)
goto out_post_unlock;
@@ -876,10 +876,8 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void
*data,
* Allocate an id which can be used by WAIT_FENCE ioctl to map back
* to the underlying fence.
*/
- mutex_lock(&queue->lock);
submit->fence_id = idr_alloc_cyclic(&queue->fence_idr,
submit->user_fence, 0, INT_MAX, GFP_KERNEL);
- mutex_unlock(&queue->lock);
if (submit->fence_id < 0) {
ret = submit->fence_id = 0;
submit->fence_id = 0;
@@ -914,12 +912,12 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void
*data,
submit_cleanup(submit, !!ret);
if (has_ww_ticket)
ww_acquire_fini(&submit->ticket);
- msm_gem_submit_put(submit);
out_unlock:
if (ret && (out_fence_fd >= 0))
put_unused_fd(out_fence_fd);
- mutex_unlock(&dev->struct_mutex);
-
+ mutex_unlock(&queue->lock);
+ if (submit)
+ msm_gem_submit_put(submit);
out_post_unlock:
if (!IS_ERR_OR_NULL(post_deps)) {
for (i = 0; i < args->nr_out_syncobjs; ++i) {
--
2.31.1
[PATCH v2 07/12] drm/msm: Track "seqno" fences by idr
From: Rob Clark
Previously the (non-fd) fence returned from submit ioctl was a raw
seqno, which is scoped to the ring. But from UABI standpoint, the
ioctls related to seqno fences all specify a submitqueue. We can
take advantage of that to replace the seqno fences with a cyclic idr
handle.
This is in preperation for moving to drm scheduler, at which point
the submit ioctl will return after queuing the submit job to the
scheduler, but before the submit is written into the ring (and
therefore before a ring seqno has been assigned). Which means we
need to replace the dma_fence that userspace may need to wait on
with a scheduler fence.
Signed-off-by: Rob Clark
Acked-by: Christian König
---
drivers/gpu/drm/msm/msm_drv.c | 30 +++--
drivers/gpu/drm/msm/msm_fence.c | 39 ---
drivers/gpu/drm/msm/msm_fence.h | 2 --
drivers/gpu/drm/msm/msm_gem.h | 1 +
drivers/gpu/drm/msm/msm_gem_submit.c | 23 +++-
drivers/gpu/drm/msm/msm_gpu.h | 5
drivers/gpu/drm/msm/msm_submitqueue.c | 5
7 files changed, 61 insertions(+), 44 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 9b8fa2ad0d84..1594ae39d54f 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -911,6 +911,7 @@ static int msm_ioctl_wait_fence(struct drm_device *dev,
void *data,
ktime_t timeout = to_ktime(args->timeout);
struct msm_gpu_submitqueue *queue;
struct msm_gpu *gpu = priv->gpu;
+ struct dma_fence *fence;
int ret;
if (args->pad) {
@@ -925,10 +926,35 @@ static int msm_ioctl_wait_fence(struct drm_device *dev,
void *data,
if (!queue)
return -ENOENT;
- ret = msm_wait_fence(gpu->rb[queue->prio]->fctx, args->fence, &timeout,
- true);
+ /*
+* Map submitqueue scoped "seqno" (which is actually an idr key)
+* back to underlying dma-fence
+*
+* The fence is removed from the fence_idr when the submit is
+* retired, so if the fence is not found it means there is nothing
+* to wait for
+*/
+ ret = mutex_lock_interruptible(&queue->lock);
+ if (ret)
+ return ret;
+ fence = idr_find(&queue->fence_idr, args->fence);
+ if (fence)
+ fence = dma_fence_get_rcu(fence);
+ mutex_unlock(&queue->lock);
+
+ if (!fence)
+ return 0;
+ ret = dma_fence_wait_timeout(fence, true, timeout_to_jiffies(&timeout));
+ if (ret == 0) {
+ ret = -ETIMEDOUT;
+ } else if (ret != -ERESTARTSYS) {
+ ret = 0;
+ }
+
+ dma_fence_put(fence);
msm_submitqueue_put(queue);
+
return ret;
}
diff --git a/drivers/gpu/drm/msm/msm_fence.c b/drivers/gpu/drm/msm/msm_fence.c
index b92a9091a1e2..d8228029708e 100644
--- a/drivers/gpu/drm/msm/msm_fence.c
+++ b/drivers/gpu/drm/msm/msm_fence.c
@@ -45,45 +45,6 @@ static inline bool fence_completed(struct msm_fence_context
*fctx, uint32_t fenc
(int32_t)(*fctx->fenceptr - fence) >= 0;
}
-/* legacy path for WAIT_FENCE ioctl: */
-int msm_wait_fence(struct msm_fence_context *fctx, uint32_t fence,
- ktime_t *timeout, bool interruptible)
-{
- int ret;
-
- if (fence > fctx->last_fence) {
- DRM_ERROR_RATELIMITED("%s: waiting on invalid fence: %u (of
%u)\n",
- fctx->name, fence, fctx->last_fence);
- return -EINVAL;
- }
-
- if (!timeout) {
- /* no-wait: */
- ret = fence_completed(fctx, fence) ? 0 : -EBUSY;
- } else {
- unsigned long remaining_jiffies = timeout_to_jiffies(timeout);
-
- if (interruptible)
- ret = wait_event_interruptible_timeout(fctx->event,
- fence_completed(fctx, fence),
- remaining_jiffies);
- else
- ret = wait_event_timeout(fctx->event,
- fence_completed(fctx, fence),
- remaining_jiffies);
-
- if (ret == 0) {
- DBG("timeout waiting for fence: %u (completed: %u)",
- fence, fctx->completed_fence);
- ret = -ETIMEDOUT;
- } else if (ret != -ERESTARTSYS) {
- ret = 0;
- }
- }
-
- return ret;
-}
-
/* called from workqueue */
void msm_update_fence(struct msm_fence_context *fctx, uint32_t fence)
{
diff --git a/drivers/gpu/drm/msm/msm_fence.h b/drivers/gpu/drm/msm/msm_fence.h
index 6ab97062ff1a..6de97d0f5153 100644
--- a/drivers/gpu/drm/msm/msm_fence.h
+++ b/drivers/gpu/drm/msm/msm_fence.h
@@ -57,8 +57,6 @@ struct msm_fence_context * msm_fence_context_alloc(struct
drm_device *dev,
[PATCH v2 11/12] drm/msm: Utilize gpu scheduler priorities
From: Rob Clark
The drm/scheduler provides additional prioritization on top of that
provided by however many number of ringbuffers (each with their own
priority level) is supported on a given generation. Expose the
additional levels of priority to userspace and map the userspace
priority back to ring (first level of priority) and schedular priority
(additional priority levels within the ring).
Signed-off-by: Rob Clark
Acked-by: Christian König
---
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 4 +-
drivers/gpu/drm/msm/msm_gem_submit.c| 4 +-
drivers/gpu/drm/msm/msm_gpu.h | 58 -
drivers/gpu/drm/msm/msm_submitqueue.c | 35 +++
include/uapi/drm/msm_drm.h | 14 +-
5 files changed, 88 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index bad4809b68ef..748665232d29 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -261,8 +261,8 @@ int adreno_get_param(struct msm_gpu *gpu, uint32_t param,
uint64_t *value)
return ret;
}
return -EINVAL;
- case MSM_PARAM_NR_RINGS:
- *value = gpu->nr_rings;
+ case MSM_PARAM_PRIORITIES:
+ *value = gpu->nr_rings * NR_SCHED_PRIORITIES;
return 0;
case MSM_PARAM_PP_PGTABLE:
*value = 0;
diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c
b/drivers/gpu/drm/msm/msm_gem_submit.c
index affceccf145d..b60c3f7ed551 100644
--- a/drivers/gpu/drm/msm/msm_gem_submit.c
+++ b/drivers/gpu/drm/msm/msm_gem_submit.c
@@ -59,7 +59,7 @@ static struct msm_gem_submit *submit_create(struct drm_device
*dev,
submit->gpu = gpu;
submit->cmd = (void *)&submit->bos[nr_bos];
submit->queue = queue;
- submit->ring = gpu->rb[queue->prio];
+ submit->ring = gpu->rb[queue->ring_nr];
submit->fault_dumped = false;
INIT_LIST_HEAD(&submit->node);
@@ -751,7 +751,7 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void *data,
/* Get a unique identifier for the submission for logging purposes */
submitid = atomic_inc_return(&ident) - 1;
- ring = gpu->rb[queue->prio];
+ ring = gpu->rb[queue->ring_nr];
trace_msm_gpu_submit(pid_nr(pid), ring->id, submitid,
args->nr_bos, args->nr_cmds);
diff --git a/drivers/gpu/drm/msm/msm_gpu.h b/drivers/gpu/drm/msm/msm_gpu.h
index b912cacaecc0..0e4b45bff2e6 100644
--- a/drivers/gpu/drm/msm/msm_gpu.h
+++ b/drivers/gpu/drm/msm/msm_gpu.h
@@ -250,6 +250,59 @@ struct msm_gpu_perfcntr {
const char *name;
};
+/*
+ * The number of priority levels provided by drm gpu scheduler. The
+ * DRM_SCHED_PRIORITY_KERNEL priority level is treated specially in some
+ * cases, so we don't use it (no need for kernel generated jobs).
+ */
+#define NR_SCHED_PRIORITIES (1 + DRM_SCHED_PRIORITY_HIGH -
DRM_SCHED_PRIORITY_MIN)
+
+/**
+ * msm_gpu_convert_priority - Map userspace priority to ring # and sched
priority
+ *
+ * @gpu:the gpu instance
+ * @prio: the userspace priority level
+ * @ring_nr:[out] the ringbuffer the userspace priority maps to
+ * @sched_prio: [out] the gpu scheduler priority level which the userspace
+ * priority maps to
+ *
+ * With drm/scheduler providing it's own level of prioritization, our total
+ * number of available priority levels is (nr_rings * NR_SCHED_PRIORITIES).
+ * Each ring is associated with it's own scheduler instance. However, our
+ * UABI is that lower numerical values are higher priority. So mapping the
+ * single userspace priority level into ring_nr and sched_prio takes some
+ * care. The userspace provided priority (when a submitqueue is created)
+ * is mapped to ring nr and scheduler priority as such:
+ *
+ * ring_nr= userspace_prio / NR_SCHED_PRIORITIES
+ * sched_prio = NR_SCHED_PRIORITIES -
+ *(userspace_prio % NR_SCHED_PRIORITIES) - 1
+ *
+ * This allows generations without preemption (nr_rings==1) to have some
+ * amount of prioritization, and provides more priority levels for gens
+ * that do have preemption.
+ */
+static inline int msm_gpu_convert_priority(struct msm_gpu *gpu, int prio,
+ unsigned *ring_nr, enum drm_sched_priority *sched_prio)
+{
+ unsigned rn, sp;
+
+ rn = div_u64_rem(prio, NR_SCHED_PRIORITIES, &sp);
+
+ /* invert sched priority to map to higher-numeric-is-higher-
+* priority convention
+*/
+ sp = NR_SCHED_PRIORITIES - sp - 1;
+
+ if (rn >= gpu->nr_rings)
+ return -EINVAL;
+
+ *ring_nr = rn;
+ *sched_prio = sp;
+
+ return 0;
+}
+
/**
* A submitqueue is associated with a gl context or vk queue (or equiv)
* in userspace.
@@ -257,7 +310,8 @@ struct msm_gpu_perfcntr {
* @id:userspace id for the submitqueue, unique within the drm_file
* @f
[PATCH v2 12/12] drm/msm/gem: Mark active before pinning
From: Rob Clark
Mark all the bos in the submit as active, before pinning, to prevent
evicting a buffer in the same submit to make room for a buffer earlier
in the table.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem.c| 2 --
drivers/gpu/drm/msm/msm_gem_submit.c | 28
2 files changed, 20 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index 41a111c49cc7..71a589fd4ba8 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -131,7 +131,6 @@ static struct page **get_pages(struct drm_gem_object *obj)
if (msm_obj->flags & (MSM_BO_WC|MSM_BO_UNCACHED))
sync_for_device(msm_obj);
- GEM_WARN_ON(msm_obj->active_count);
update_inactive(msm_obj);
}
@@ -815,7 +814,6 @@ void msm_gem_active_get(struct drm_gem_object *obj, struct
msm_gpu *gpu)
GEM_WARN_ON(!msm_gem_is_locked(obj));
GEM_WARN_ON(msm_obj->madv != MSM_MADV_WILLNEED);
GEM_WARN_ON(msm_obj->dontneed);
- GEM_WARN_ON(!msm_obj->sgt);
if (msm_obj->active_count++ == 0) {
mutex_lock(&priv->mm_lock);
diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c
b/drivers/gpu/drm/msm/msm_gem_submit.c
index b60c3f7ed551..2615a4b3a2e9 100644
--- a/drivers/gpu/drm/msm/msm_gem_submit.c
+++ b/drivers/gpu/drm/msm/msm_gem_submit.c
@@ -24,7 +24,8 @@
/* make sure these don't conflict w/ MSM_SUBMIT_BO_x */
#define BO_VALID0x8000 /* is current addr in cmdstream correct/valid? */
#define BO_LOCKED 0x4000 /* obj lock is held */
-#define BO_PINNED 0x2000 /* obj is pinned and on active list */
+#define BO_ACTIVE 0x2000 /* active refcnt is held */
+#define BO_PINNED 0x1000 /* obj is pinned and on active list */
static struct msm_gem_submit *submit_create(struct drm_device *dev,
struct msm_gpu *gpu,
@@ -252,10 +253,11 @@ static void submit_cleanup_bo(struct msm_gem_submit
*submit, int i,
struct drm_gem_object *obj = &submit->bos[i].obj->base;
unsigned flags = submit->bos[i].flags & cleanup_flags;
- if (flags & BO_PINNED) {
+ if (flags & BO_PINNED)
msm_gem_unpin_iova_locked(obj, submit->aspace);
+
+ if (flags & BO_ACTIVE)
msm_gem_active_put(obj);
- }
if (flags & BO_LOCKED)
dma_resv_unlock(obj->resv);
@@ -265,7 +267,7 @@ static void submit_cleanup_bo(struct msm_gem_submit
*submit, int i,
static void submit_unlock_unpin_bo(struct msm_gem_submit *submit, int i)
{
- submit_cleanup_bo(submit, i, BO_PINNED | BO_LOCKED);
+ submit_cleanup_bo(submit, i, BO_PINNED | BO_ACTIVE | BO_LOCKED);
if (!(submit->bos[i].flags & BO_VALID))
submit->bos[i].iova = 0;
@@ -357,6 +359,18 @@ static int submit_pin_objects(struct msm_gem_submit
*submit)
submit->valid = true;
+ /*
+* Increment active_count first, so if under memory pressure, we
+* don't inadvertently evict a bo needed by the submit in order
+* to pin an earlier bo in the same submit.
+*/
+ for (i = 0; i < submit->nr_bos; i++) {
+ struct drm_gem_object *obj = &submit->bos[i].obj->base;
+
+ msm_gem_active_get(obj, submit->gpu);
+ submit->bos[i].flags |= BO_ACTIVE;
+ }
+
for (i = 0; i < submit->nr_bos; i++) {
struct drm_gem_object *obj = &submit->bos[i].obj->base;
uint64_t iova;
@@ -368,8 +382,6 @@ static int submit_pin_objects(struct msm_gem_submit *submit)
if (ret)
break;
- msm_gem_active_get(obj, submit->gpu);
-
submit->bos[i].flags |= BO_PINNED;
if (iova == submit->bos[i].iova) {
@@ -503,7 +515,7 @@ static void submit_cleanup(struct msm_gem_submit *submit,
bool error)
unsigned i;
if (error)
- cleanup_flags |= BO_PINNED;
+ cleanup_flags |= BO_PINNED | BO_ACTIVE;
for (i = 0; i < submit->nr_bos; i++) {
struct msm_gem_object *msm_obj = submit->bos[i].obj;
@@ -522,7 +534,7 @@ void msm_submit_retire(struct msm_gem_submit *submit)
struct drm_gem_object *obj = &submit->bos[i].obj->base;
msm_gem_lock(obj);
- submit_cleanup_bo(submit, i, BO_PINNED);
+ submit_cleanup_bo(submit, i, BO_PINNED | BO_ACTIVE);
msm_gem_unlock(obj);
drm_gem_object_put(obj);
}
--
2.31.1
RE: [PATCH v5 02/15] mei: pxp: export pavp client to me client bus
> From: Vitaly Lubart
>
> Export PAVP client to work with i915 driver, for binding it uses kernel
> component framework.
>
> Signed-off-by: Vitaly Lubart
> Signed-off-by: Tomas Winkler
> Signed-off-by: Daniele Ceraolo Spurio
> Reviewed-by: Rodrigo Vivi
> ---
> drivers/misc/mei/Kconfig | 2 +
> drivers/misc/mei/Makefile | 1 +
> drivers/misc/mei/pxp/Kconfig | 13 ++
> drivers/misc/mei/pxp/Makefile | 7 +
> drivers/misc/mei/pxp/mei_pxp.c | 233
> +
> drivers/misc/mei/pxp/mei_pxp.h | 18 +++
> 6 files changed, 274 insertions(+)
> create mode 100644 drivers/misc/mei/pxp/Kconfig create mode 100644
> drivers/misc/mei/pxp/Makefile create mode 100644
> drivers/misc/mei/pxp/mei_pxp.c create mode 100644
> drivers/misc/mei/pxp/mei_pxp.h
>
> diff --git a/drivers/misc/mei/Kconfig b/drivers/misc/mei/Kconfig index
> f5fd5b786607..0e0bcd0da852 100644
> --- a/drivers/misc/mei/Kconfig
> +++ b/drivers/misc/mei/Kconfig
> @@ -47,3 +47,5 @@ config INTEL_MEI_TXE
> Intel Bay Trail
>
> source "drivers/misc/mei/hdcp/Kconfig"
> +source "drivers/misc/mei/pxp/Kconfig"
> +
> diff --git a/drivers/misc/mei/Makefile b/drivers/misc/mei/Makefile index
> f1c76f7ee804..d8e5165917f2 100644
> --- a/drivers/misc/mei/Makefile
> +++ b/drivers/misc/mei/Makefile
> @@ -26,3 +26,4 @@ mei-$(CONFIG_EVENT_TRACING) += mei-trace.o
> CFLAGS_mei-trace.o = -I$(src)
>
> obj-$(CONFIG_INTEL_MEI_HDCP) += hdcp/
> +obj-$(CONFIG_INTEL_MEI_PXP) += pxp/
> diff --git a/drivers/misc/mei/pxp/Kconfig b/drivers/misc/mei/pxp/Kconfig
> new file mode 100644 index ..4029b96afc04
> --- /dev/null
> +++ b/drivers/misc/mei/pxp/Kconfig
> @@ -0,0 +1,13 @@
> +
> +# SPDX-License-Identifier: GPL-2.0
> +# Copyright (c) 2020, Intel Corporation. All rights reserved.
2020-2021
> +#
> +config INTEL_MEI_PXP
> + tristate "Intel PXP services of ME Interface"
> + select INTEL_MEI_ME
> + depends on DRM_I915
> + help
> + MEI Support for PXP Services on Intel platforms.
> +
> + Enables the ME FW services required for PXP support through
> + I915 display driver of Intel.
> diff --git a/drivers/misc/mei/pxp/Makefile b/drivers/misc/mei/pxp/Makefile
> new file mode 100644 index ..0329950d5794
> --- /dev/null
> +++ b/drivers/misc/mei/pxp/Makefile
> @@ -0,0 +1,7 @@
> +# SPDX-License-Identifier: GPL-2.0
> +#
> +# Copyright (c) 2020, Intel Corporation. All rights reserved.
> +#
> +# Makefile - PXP client driver for Intel MEI Bus Driver.
> +
> +obj-$(CONFIG_INTEL_MEI_PXP) += mei_pxp.o
> diff --git a/drivers/misc/mei/pxp/mei_pxp.c
> b/drivers/misc/mei/pxp/mei_pxp.c new file mode 100644 index
> ..cacfbedb640a
> --- /dev/null
> +++ b/drivers/misc/mei/pxp/mei_pxp.c
> @@ -0,0 +1,233 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright © 2020 Intel Corporation
> + */
> +
> +/**
> + * DOC: MEI_PXP Client Driver
> + *
> + * The mei_pxp driver acts as a translation layer between PXP
> + * protocol implementer (I915) and ME FW by translating PXP
> + * negotiation messages to ME FW command payloads and vice versa.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "mei_pxp.h"
> +
> +/**
> + * mei_pxp_send_message() - Sends a PXP message to ME FW.
> + * @dev: device corresponding to the mei_cl_device
> + * @message: a message buffer to send
> + * @size: size of the message
> + * Return: 0 on Success, <0 on Failure
> + */
> +static int
> +mei_pxp_send_message(struct device *dev, const void *message, size_t
> +size) {
> + struct mei_cl_device *cldev;
> + ssize_t byte;
> +
> + if (!dev || !message)
> + return -EINVAL;
> +
> + cldev = to_mei_cl_device(dev);
> +
> + /* temporary drop const qualifier till the API is fixed */
> + byte = mei_cldev_send(cldev, (u8 *)message, size);
> + if (byte < 0) {
> + dev_dbg(dev, "mei_cldev_send failed. %zd\n", byte);
> + return byte;
> + }
> +
> + return 0;
> +}
> +
> +/**
> + * mei_pxp_receive_message() - Receives a PXP message from ME FW.
> + * @dev: device corresponding to the mei_cl_device
> + * @buffer: a message buffer to contain the received message
> + * @size: size of the buffer
> + * Return: bytes sent on Success, <0 on Failure */ static int
> +mei_pxp_receive_message(struct device *dev, void *buffer, size_t size)
> +{
> + struct mei_cl_device *cldev;
> + ssize_t byte;
> +
> + if (!dev || !buffer)
> + return -EINVAL;
> +
> + cldev = to_mei_cl_device(dev);
> +
> + byte = mei_cldev_recv(cldev, buffer, size);
> + if (byte < 0) {
> + dev_dbg(dev, "mei_cldev_recv failed. %zd\n", byte);
> + return byte;
> + }
> +
> + return byte;
> +}
> +
> +static const struct i915_pxp_component_ops mei_pxp_ops = {
> + .owner = THIS_MODULE,
> + .send = mei_pxp_send_message,
> + .recv = mei_pxp_receive_message,
Re: [PATCH 18/30] drm/i915: remove explicit CNL handling from i915_irq.c
On Mon, Jul 26, 2021 at 06:59:35AM -0400, Rodrigo Vivi wrote:
On Fri, Jul 23, 2021 at 05:11:02PM -0700, Lucas De Marchi wrote:
Remove special handling of PORT_F in i915_irq.c and only do it for
DISPLAY_VER == 11.
oh! ignore my previous thought about removing the port F...
of course I only saw this after replying to your comment :)
thanks
Lucas De Marchi
Signed-off-by: Lucas De Marchi
Reviewed-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/i915_irq.c | 7 +++
drivers/gpu/drm/i915/i915_reg.h | 2 +-
2 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index e2171bd2820e..17d336218b67 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2297,11 +2297,10 @@ static u32 gen8_de_port_aux_mask(struct
drm_i915_private *dev_priv)
GEN9_AUX_CHANNEL_C |
GEN9_AUX_CHANNEL_D;
- if (IS_CNL_WITH_PORT_F(dev_priv) || DISPLAY_VER(dev_priv) == 11)
- mask |= CNL_AUX_CHANNEL_F;
-
- if (DISPLAY_VER(dev_priv) == 11)
+ if (DISPLAY_VER(dev_priv) == 11) {
+ mask |= ICL_AUX_CHANNEL_F;
mask |= ICL_AUX_CHANNEL_E;
+ }
return mask;
}
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index d198b1a2d4b5..fdc8fd424d36 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7945,7 +7945,7 @@ enum {
#define DSI1_NON_TE (1 << 31)
#define DSI0_NON_TE (1 << 30)
#define ICL_AUX_CHANNEL_E (1 << 29)
-#define CNL_AUX_CHANNEL_F (1 << 28)
+#define ICL_AUX_CHANNEL_F (1 << 28)
#define GEN9_AUX_CHANNEL_D(1 << 27)
#define GEN9_AUX_CHANNEL_C(1 << 26)
#define GEN9_AUX_CHANNEL_B(1 << 25)
--
2.31.1
Re: [Intel-gfx] [PATCH 0/8] drm/i915: Migrate memory to SMEM when imported cross-device (v8)
On Mon, Jul 26, 2021 at 3:12 AM Matthew Auld wrote: > > On Fri, 23 Jul 2021 at 18:21, Jason Ekstrand wrote: > > > > This patch series fixes an issue with discrete graphics on Intel where we > > allowed dma-buf import while leaving the object in local memory. This > > breaks down pretty badly if the import happened on a different physical > > device. > > > > v7: > > - Drop "drm/i915/gem/ttm: Place new BOs in the requested region" > > - Add a new "drm/i915/gem: Call i915_gem_flush_free_objects() in > > i915_gem_dumb_create()" > > - Misc. review feedback from Matthew Auld > > v8: > > - Misc. review feedback from Matthew Auld > > v9: > > - Replace the i915/ttm patch with two that are hopefully more correct > > > > Jason Ekstrand (6): > > drm/i915/gem: Check object_can_migrate from object_migrate > > drm/i915/gem: Refactor placement setup for i915_gem_object_create* > > (v2) > > drm/i915/gem: Call i915_gem_flush_free_objects() in > > i915_gem_dumb_create() > > drm/i915/gem: Unify user object creation (v3) > > drm/i915/gem/ttm: Only call __i915_gem_object_set_pages if needed > > drm/i915/gem: Always call obj->ops->migrate unless can_migrate fails > > > > Thomas Hellström (2): > > drm/i915/gem: Correct the locking and pin pattern for dma-buf (v8) > > drm/i915/gem: Migrate to system at dma-buf attach time (v7) > > Should I push the series? Yes, please. Do we have a solid testing plan for things like this that touch discrete? I tested with mesa+glxgears on my DG1 but haven't run anything more stressful. --Jason > > > > drivers/gpu/drm/i915/gem/i915_gem_create.c| 177 > > drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c| 58 -- > > drivers/gpu/drm/i915/gem/i915_gem_object.c| 20 +- > > drivers/gpu/drm/i915/gem/i915_gem_object.h| 4 + > > drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 13 +- > > .../drm/i915/gem/selftests/i915_gem_dmabuf.c | 190 +- > > .../drm/i915/gem/selftests/i915_gem_migrate.c | 15 -- > > 7 files changed, 341 insertions(+), 136 deletions(-) > > > > -- > > 2.31.1 > > > > ___ > > Intel-gfx mailing list > > intel-...@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/userptr: Probe existence of backing struct pages upon creation
On Mon, Jul 26, 2021 at 3:06 AM Matthew Auld
wrote:
>
> On Fri, 23 Jul 2021 at 18:48, Jason Ekstrand wrote:
> >
> > https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12044
>
> Cool, is that ready to go? i.e can we start merging the kernel + IGT side.
Yes, it's all reviewed. Though, it sounds like Maarten had a comment
so we should settle on that before landing.
> >
> > On Fri, Jul 23, 2021 at 6:35 AM Matthew Auld wrote:
> > >
> > > From: Chris Wilson
> > >
> > > Jason Ekstrand requested a more efficient method than userptr+set-domain
> > > to determine if the userptr object was backed by a complete set of pages
> > > upon creation. To be more efficient than simply populating the userptr
> > > using get_user_pages() (as done by the call to set-domain or execbuf),
> > > we can walk the tree of vm_area_struct and check for gaps or vma not
> > > backed by struct page (VM_PFNMAP). The question is how to handle
> > > VM_MIXEDMAP which may be either struct page or pfn backed...
> > >
> > > With discrete we are going to drop support for set_domain(), so offering
> > > a way to probe the pages, without having to resort to dummy batches has
> > > been requested.
> > >
> > > v2:
> > > - add new query param for the PROBE flag, so userspace can easily
> > > check if the kernel supports it(Jason).
> > > - use mmap_read_{lock, unlock}.
> > > - add some kernel-doc.
> > > v3:
> > > - In the docs also mention that PROBE doesn't guarantee that the pages
> > > will remain valid by the time they are actually used(Tvrtko).
> > > - Add a small comment for the hole finding logic(Jason).
> > > - Move the param next to all the other params which just return true.
> > >
> > > Testcase: igt/gem_userptr_blits/probe
> > > Signed-off-by: Chris Wilson
> > > Signed-off-by: Matthew Auld
> > > Cc: Thomas Hellström
> > > Cc: Maarten Lankhorst
> > > Cc: Tvrtko Ursulin
> > > Cc: Jordan Justen
> > > Cc: Kenneth Graunke
> > > Cc: Jason Ekstrand
> > > Cc: Daniel Vetter
> > > Cc: Ramalingam C
> > > Reviewed-by: Tvrtko Ursulin
> > > Acked-by: Kenneth Graunke
> > > Reviewed-by: Jason Ekstrand
> > > ---
> > > drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 41 -
> > > drivers/gpu/drm/i915/i915_getparam.c| 1 +
> > > include/uapi/drm/i915_drm.h | 20 ++
> > > 3 files changed, 61 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
> > > b/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
> > > index 56edfeff8c02..468a7a617fbf 100644
> > > --- a/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
> > > +++ b/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
> > > @@ -422,6 +422,34 @@ static const struct drm_i915_gem_object_ops
> > > i915_gem_userptr_ops = {
> > >
> > > #endif
> > >
> > > +static int
> > > +probe_range(struct mm_struct *mm, unsigned long addr, unsigned long len)
> > > +{
> > > + const unsigned long end = addr + len;
> > > + struct vm_area_struct *vma;
> > > + int ret = -EFAULT;
> > > +
> > > + mmap_read_lock(mm);
> > > + for (vma = find_vma(mm, addr); vma; vma = vma->vm_next) {
> > > + /* Check for holes, note that we also update the addr
> > > below */
> > > + if (vma->vm_start > addr)
> > > + break;
> > > +
> > > + if (vma->vm_flags & (VM_PFNMAP | VM_MIXEDMAP))
> > > + break;
> > > +
> > > + if (vma->vm_end >= end) {
> > > + ret = 0;
> > > + break;
> > > + }
> > > +
> > > + addr = vma->vm_end;
> > > + }
> > > + mmap_read_unlock(mm);
> > > +
> > > + return ret;
> > > +}
> > > +
> > > /*
> > > * Creates a new mm object that wraps some normal memory from the process
> > > * context - user memory.
> > > @@ -477,7 +505,8 @@ i915_gem_userptr_ioctl(struct drm_device *dev,
> > > }
> > >
> > > if (args->flags & ~(I915_USERPTR_READ_ONLY |
> > > - I915_USERPTR_UNSYNCHRONIZED))
> > > + I915_USERPTR_UNSYNCHRONIZED |
> > > + I915_USERPTR_PROBE))
> > > return -EINVAL;
> > >
> > > if (i915_gem_object_size_2big(args->user_size))
> > > @@ -504,6 +533,16 @@ i915_gem_userptr_ioctl(struct drm_device *dev,
> > > return -ENODEV;
> > > }
> > >
> > > + if (args->flags & I915_USERPTR_PROBE) {
> > > + /*
> > > +* Check that the range pointed to represents real struct
> > > +* pages and not iomappings (at this moment in time!)
> > > +*/
> > > + ret = probe_range(current->mm, args->user_ptr,
> > > args->user_size);
> > > + if (ret)
> > > + return ret;
> > > + }
> > > +
> > > #ifdef CONFIG_MMU_NOTIFIER
> > > obj = i915_gem_object_alloc();
> > > i
Re: [PATCH] drm/i915/userptr: Probe existence of backing struct pages upon creation
On Mon, Jul 26, 2021 at 3:31 AM Maarten Lankhorst
wrote:
>
> Op 23-07-2021 om 13:34 schreef Matthew Auld:
> > From: Chris Wilson
> >
> > Jason Ekstrand requested a more efficient method than userptr+set-domain
> > to determine if the userptr object was backed by a complete set of pages
> > upon creation. To be more efficient than simply populating the userptr
> > using get_user_pages() (as done by the call to set-domain or execbuf),
> > we can walk the tree of vm_area_struct and check for gaps or vma not
> > backed by struct page (VM_PFNMAP). The question is how to handle
> > VM_MIXEDMAP which may be either struct page or pfn backed...
> >
> > With discrete we are going to drop support for set_domain(), so offering
> > a way to probe the pages, without having to resort to dummy batches has
> > been requested.
> >
> > v2:
> > - add new query param for the PROBE flag, so userspace can easily
> > check if the kernel supports it(Jason).
> > - use mmap_read_{lock, unlock}.
> > - add some kernel-doc.
> > v3:
> > - In the docs also mention that PROBE doesn't guarantee that the pages
> > will remain valid by the time they are actually used(Tvrtko).
> > - Add a small comment for the hole finding logic(Jason).
> > - Move the param next to all the other params which just return true.
> >
> > Testcase: igt/gem_userptr_blits/probe
> > Signed-off-by: Chris Wilson
> > Signed-off-by: Matthew Auld
> > Cc: Thomas Hellström
> > Cc: Maarten Lankhorst
> > Cc: Tvrtko Ursulin
> > Cc: Jordan Justen
> > Cc: Kenneth Graunke
> > Cc: Jason Ekstrand
> > Cc: Daniel Vetter
> > Cc: Ramalingam C
> > Reviewed-by: Tvrtko Ursulin
> > Acked-by: Kenneth Graunke
> > Reviewed-by: Jason Ekstrand
> > ---
> > drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 41 -
> > drivers/gpu/drm/i915/i915_getparam.c| 1 +
> > include/uapi/drm/i915_drm.h | 20 ++
> > 3 files changed, 61 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
> > b/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
> > index 56edfeff8c02..468a7a617fbf 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
> > @@ -422,6 +422,34 @@ static const struct drm_i915_gem_object_ops
> > i915_gem_userptr_ops = {
> >
> > #endif
> >
> > +static int
> > +probe_range(struct mm_struct *mm, unsigned long addr, unsigned long len)
> > +{
> > + const unsigned long end = addr + len;
> > + struct vm_area_struct *vma;
> > + int ret = -EFAULT;
> > +
> > + mmap_read_lock(mm);
> > + for (vma = find_vma(mm, addr); vma; vma = vma->vm_next) {
> > + /* Check for holes, note that we also update the addr below */
> > + if (vma->vm_start > addr)
> > + break;
> > +
> > + if (vma->vm_flags & (VM_PFNMAP | VM_MIXEDMAP))
> > + break;
> > +
> > + if (vma->vm_end >= end) {
> > + ret = 0;
> > + break;
> > + }
> > +
> > + addr = vma->vm_end;
> > + }
> > + mmap_read_unlock(mm);
> > +
> > + return ret;
> > +}
> > +
> > /*
> > * Creates a new mm object that wraps some normal memory from the process
> > * context - user memory.
> > @@ -477,7 +505,8 @@ i915_gem_userptr_ioctl(struct drm_device *dev,
> > }
> >
> > if (args->flags & ~(I915_USERPTR_READ_ONLY |
> > - I915_USERPTR_UNSYNCHRONIZED))
> > + I915_USERPTR_UNSYNCHRONIZED |
> > + I915_USERPTR_PROBE))
> > return -EINVAL;
> >
> > if (i915_gem_object_size_2big(args->user_size))
> > @@ -504,6 +533,16 @@ i915_gem_userptr_ioctl(struct drm_device *dev,
> > return -ENODEV;
> > }
> >
> > + if (args->flags & I915_USERPTR_PROBE) {
> > + /*
> > + * Check that the range pointed to represents real struct
> > + * pages and not iomappings (at this moment in time!)
> > + */
> > + ret = probe_range(current->mm, args->user_ptr,
> > args->user_size);
> > + if (ret)
> > + return ret;
> > + }
> > +
> > #ifdef CONFIG_MMU_NOTIFIER
> > obj = i915_gem_object_alloc();
> > if (obj == NULL)
> > diff --git a/drivers/gpu/drm/i915/i915_getparam.c
> > b/drivers/gpu/drm/i915/i915_getparam.c
> > index 24e18219eb50..bbb7cac43eb4 100644
> > --- a/drivers/gpu/drm/i915/i915_getparam.c
> > +++ b/drivers/gpu/drm/i915/i915_getparam.c
> > @@ -134,6 +134,7 @@ int i915_getparam_ioctl(struct drm_device *dev, void
> > *data,
> > case I915_PARAM_HAS_EXEC_FENCE_ARRAY:
> > case I915_PARAM_HAS_EXEC_SUBMIT_FENCE:
> > case I915_PARAM_HAS_EXEC_TIMELINE_FENCES:
> > + case I915_PARAM_HAS_USERPTR_PROBE:
> > /* For the time being all of these are always true;
> >* if some supported hard
Re: [PATCH 04/10] drm/bridge: Document the probe issue with MIPI-DSI bridges
Hi Daniel, On Wed, Jul 21, 2021 at 02:05:01PM +0200, Daniel Vetter wrote: > On Tue, Jul 20, 2021 at 03:45:19PM +0200, Maxime Ripard wrote: > > Interactions between bridges, panels, MIPI-DSI host and the component > > framework are not trivial and can lead to probing issues when > > implementing a display driver. Let's document the various cases we need > > too consider, and the solution to support all the cases. > > > > Signed-off-by: Maxime Ripard > > I still have this dream that eventually we resurrect a patch to add > device_link to bridges/panels (ideally automatically), to help with some > of the suspend/resume issues around here. > > Will this make things worse? > > I think it'd be really good to figure that out with some coding, since if > we have incompatible solution to handle probe issues vs suspend/resume > issues, we're screwed. > > Atm the duct-tape is to carefully move things around between suspend and > suspend_early hooks (and resume and resume_late) and hope it all works ... My initial idea to fix this was indeed to use device links. I gave up after a while since it doesn't look like there's a way to add a device link before either the bridge or encoder probes. Indeed the OF-Graph representation is device-specific, so it can't be generic, and if you need to probe to add that link, well, it's already too late for the probe ordering :) Maxime signature.asc Description: PGP signature
Re: [PATCH 01/10] drm/i915: Check for nomodeset in i915_init() first
On Fri, Jul 23, 2021 at 2:29 PM Daniel Vetter wrote:
>
> When modesetting (aka the full pci driver, which has nothing to do
> with disable_display option, which just gives you the full pci driver
> without the display driver) is disabled, we load nothing and do
> nothing.
>
> So move that check first, for a bit of orderliness. With Jason's
> module init/exit table this now becomes trivial.
>
> Cc: Jason Ekstrand
> Signed-off-by: Daniel Vetter
Reviewed-by: Jason Ekstrand
> ---
> drivers/gpu/drm/i915/i915_pci.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index 48ea23dd3b5b..0deaeeba2347 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -1292,9 +1292,9 @@ static const struct {
> int (*init)(void);
> void (*exit)(void);
> } init_funcs[] = {
> + { i915_check_nomodeset, NULL },
> { i915_globals_init, i915_globals_exit },
> { i915_mock_selftests, NULL },
> - { i915_check_nomodeset, NULL },
> { i915_pmu_init, i915_pmu_exit },
> { i915_register_pci_driver, i915_unregister_pci_driver },
> { i915_perf_sysctl_register, i915_perf_sysctl_unregister },
> --
> 2.32.0
>
Re: [PATCH 02/10] drm/i915: move i915_active slab to direct module init/exit
On Fri, Jul 23, 2021 at 2:29 PM Daniel Vetter wrote:
>
> With the global kmem_cache shrink infrastructure gone there's nothing
> special and we can convert them over.
>
> I'm doing this split up into each patch because there's quite a bit of
> noise with removing the static global.slab_cache to just a slab_cache.
>
> Cc: Jason Ekstrand
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/i915_active.c | 31 ++---
> drivers/gpu/drm/i915/i915_active.h | 3 +++
> drivers/gpu/drm/i915/i915_globals.c | 2 --
> drivers/gpu/drm/i915/i915_globals.h | 1 -
> drivers/gpu/drm/i915/i915_pci.c | 2 ++
> 5 files changed, 16 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_active.c
> b/drivers/gpu/drm/i915/i915_active.c
> index 91723123ae9f..9ffeb77eb5bb 100644
> --- a/drivers/gpu/drm/i915/i915_active.c
> +++ b/drivers/gpu/drm/i915/i915_active.c
> @@ -13,7 +13,6 @@
>
> #include "i915_drv.h"
> #include "i915_active.h"
> -#include "i915_globals.h"
>
> /*
> * Active refs memory management
> @@ -22,10 +21,7 @@
> * they idle (when we know the active requests are inactive) and allocate the
> * nodes from a local slab cache to hopefully reduce the fragmentation.
> */
> -static struct i915_global_active {
> - struct i915_global base;
> - struct kmem_cache *slab_cache;
> -} global;
> +struct kmem_cache *slab_cache;
static? Or were you planning to expose it somehow? With that fixed,
Reviewed-by: Jason Ekstrand
>
> struct active_node {
> struct rb_node node;
> @@ -174,7 +170,7 @@ __active_retire(struct i915_active *ref)
> /* Finally free the discarded timeline tree */
> rbtree_postorder_for_each_entry_safe(it, n, &root, node) {
> GEM_BUG_ON(i915_active_fence_isset(&it->base));
> - kmem_cache_free(global.slab_cache, it);
> + kmem_cache_free(slab_cache, it);
> }
> }
>
> @@ -322,7 +318,7 @@ active_instance(struct i915_active *ref, u64 idx)
> * XXX: We should preallocate this before i915_active_ref() is ever
> * called, but we cannot call into fs_reclaim() anyway, so use
> GFP_ATOMIC.
> */
> - node = kmem_cache_alloc(global.slab_cache, GFP_ATOMIC);
> + node = kmem_cache_alloc(slab_cache, GFP_ATOMIC);
> if (!node)
> goto out;
>
> @@ -788,7 +784,7 @@ void i915_active_fini(struct i915_active *ref)
> mutex_destroy(&ref->mutex);
>
> if (ref->cache)
> - kmem_cache_free(global.slab_cache, ref->cache);
> + kmem_cache_free(slab_cache, ref->cache);
> }
>
> static inline bool is_idle_barrier(struct active_node *node, u64 idx)
> @@ -908,7 +904,7 @@ int i915_active_acquire_preallocate_barrier(struct
> i915_active *ref,
> node = reuse_idle_barrier(ref, idx);
> rcu_read_unlock();
> if (!node) {
> - node = kmem_cache_alloc(global.slab_cache,
> GFP_KERNEL);
> + node = kmem_cache_alloc(slab_cache, GFP_KERNEL);
> if (!node)
> goto unwind;
>
> @@ -956,7 +952,7 @@ int i915_active_acquire_preallocate_barrier(struct
> i915_active *ref,
> atomic_dec(&ref->count);
> intel_engine_pm_put(barrier_to_engine(node));
>
> - kmem_cache_free(global.slab_cache, node);
> + kmem_cache_free(slab_cache, node);
> }
> return -ENOMEM;
> }
> @@ -1176,21 +1172,16 @@ struct i915_active *i915_active_create(void)
> #include "selftests/i915_active.c"
> #endif
>
> -static void i915_global_active_exit(void)
> +void i915_active_module_exit(void)
> {
> - kmem_cache_destroy(global.slab_cache);
> + kmem_cache_destroy(slab_cache);
> }
>
> -static struct i915_global_active global = { {
> - .exit = i915_global_active_exit,
> -} };
> -
> -int __init i915_global_active_init(void)
> +int __init i915_active_module_init(void)
> {
> - global.slab_cache = KMEM_CACHE(active_node, SLAB_HWCACHE_ALIGN);
> - if (!global.slab_cache)
> + slab_cache = KMEM_CACHE(active_node, SLAB_HWCACHE_ALIGN);
> + if (!slab_cache)
> return -ENOMEM;
>
> - i915_global_register(&global.base);
> return 0;
> }
> diff --git a/drivers/gpu/drm/i915/i915_active.h
> b/drivers/gpu/drm/i915/i915_active.h
> index d0feda68b874..5fcdb0e2bc9e 100644
> --- a/drivers/gpu/drm/i915/i915_active.h
> +++ b/drivers/gpu/drm/i915/i915_active.h
> @@ -247,4 +247,7 @@ static inline int __i915_request_await_exclusive(struct
> i915_request *rq,
> return err;
> }
>
> +void i915_active_module_exit(void);
> +int i915_active_module_init(void);
> +
> #endif /* _I915_ACTIVE_H_ */
> diff --git a/drivers/gpu/drm/i915/i915_globals.c
> b/drivers/gpu/drm/i915/i915_globals.c
> index 91198f5b0a06..a53135ee831d 100644
> --- a/drivers/gpu/drm/i915/i915_globals.c
> +++
Re: [PATCH 03/10] drm/i915: move i915_buddy slab to direct module init/exit
On Fri, Jul 23, 2021 at 2:29 PM Daniel Vetter wrote:
>
> With the global kmem_cache shrink infrastructure gone there's nothing
> special and we can convert them over.
>
> I'm doing this split up into each patch because there's quite a bit of
> noise with removing the static global.slab_blocks to just a
> slab_blocks.
>
> Cc: Jason Ekstrand
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/i915_buddy.c | 25 -
> drivers/gpu/drm/i915/i915_buddy.h | 3 ++-
> drivers/gpu/drm/i915/i915_globals.c | 2 --
> drivers/gpu/drm/i915/i915_pci.c | 2 ++
> 4 files changed, 12 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_buddy.c
> b/drivers/gpu/drm/i915/i915_buddy.c
> index caabcaea3be7..045d00c43b4c 100644
> --- a/drivers/gpu/drm/i915/i915_buddy.c
> +++ b/drivers/gpu/drm/i915/i915_buddy.c
> @@ -8,13 +8,9 @@
> #include "i915_buddy.h"
>
> #include "i915_gem.h"
> -#include "i915_globals.h"
> #include "i915_utils.h"
>
> -static struct i915_global_buddy {
> - struct i915_global base;
> - struct kmem_cache *slab_blocks;
> -} global;
> +struct kmem_cache *slab_blocks;
static? With that fixed,
Reviewed-by: Jason Ekstrand
>
> static struct i915_buddy_block *i915_block_alloc(struct i915_buddy_mm *mm,
> struct i915_buddy_block
> *parent,
> @@ -25,7 +21,7 @@ static struct i915_buddy_block *i915_block_alloc(struct
> i915_buddy_mm *mm,
>
> GEM_BUG_ON(order > I915_BUDDY_MAX_ORDER);
>
> - block = kmem_cache_zalloc(global.slab_blocks, GFP_KERNEL);
> + block = kmem_cache_zalloc(slab_blocks, GFP_KERNEL);
> if (!block)
> return NULL;
>
> @@ -40,7 +36,7 @@ static struct i915_buddy_block *i915_block_alloc(struct
> i915_buddy_mm *mm,
> static void i915_block_free(struct i915_buddy_mm *mm,
> struct i915_buddy_block *block)
> {
> - kmem_cache_free(global.slab_blocks, block);
> + kmem_cache_free(slab_blocks, block);
> }
>
> static void mark_allocated(struct i915_buddy_block *block)
> @@ -410,21 +406,16 @@ int i915_buddy_alloc_range(struct i915_buddy_mm *mm,
> #include "selftests/i915_buddy.c"
> #endif
>
> -static void i915_global_buddy_exit(void)
> +void i915_buddy_module_exit(void)
> {
> - kmem_cache_destroy(global.slab_blocks);
> + kmem_cache_destroy(slab_blocks);
> }
>
> -static struct i915_global_buddy global = { {
> - .exit = i915_global_buddy_exit,
> -} };
> -
> -int __init i915_global_buddy_init(void)
> +int __init i915_buddy_module_init(void)
> {
> - global.slab_blocks = KMEM_CACHE(i915_buddy_block, 0);
> - if (!global.slab_blocks)
> + slab_blocks = KMEM_CACHE(i915_buddy_block, 0);
> + if (!slab_blocks)
> return -ENOMEM;
>
> - i915_global_register(&global.base);
> return 0;
> }
> diff --git a/drivers/gpu/drm/i915/i915_buddy.h
> b/drivers/gpu/drm/i915/i915_buddy.h
> index d8f26706de52..3940d632f208 100644
> --- a/drivers/gpu/drm/i915/i915_buddy.h
> +++ b/drivers/gpu/drm/i915/i915_buddy.h
> @@ -129,6 +129,7 @@ void i915_buddy_free(struct i915_buddy_mm *mm, struct
> i915_buddy_block *block);
>
> void i915_buddy_free_list(struct i915_buddy_mm *mm, struct list_head
> *objects);
>
> -int i915_global_buddy_init(void);
> +void i915_buddy_module_exit(void);
> +int i915_buddy_module_init(void);
>
> #endif
> diff --git a/drivers/gpu/drm/i915/i915_globals.c
> b/drivers/gpu/drm/i915/i915_globals.c
> index a53135ee831d..3de7cf22ec76 100644
> --- a/drivers/gpu/drm/i915/i915_globals.c
> +++ b/drivers/gpu/drm/i915/i915_globals.c
> @@ -7,7 +7,6 @@
> #include
> #include
>
> -#include "i915_buddy.h"
> #include "gem/i915_gem_context.h"
> #include "gem/i915_gem_object.h"
> #include "i915_globals.h"
> @@ -33,7 +32,6 @@ static void __i915_globals_cleanup(void)
> }
>
> static __initconst int (* const initfn[])(void) = {
> - i915_global_buddy_init,
> i915_global_context_init,
> i915_global_gem_context_init,
> i915_global_objects_init,
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index 6ee77a8f43d6..f9527269e30a 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -31,6 +31,7 @@
> #include "display/intel_fbdev.h"
>
> #include "i915_active.h"
> +#include "i915_buddy.h"
> #include "i915_drv.h"
> #include "i915_perf.h"
> #include "i915_globals.h"
> @@ -1295,6 +1296,7 @@ static const struct {
> } init_funcs[] = {
> { i915_check_nomodeset, NULL },
> { i915_active_module_init, i915_active_module_exit },
> + { i915_buddy_module_init, i915_buddy_module_exit },
> { i915_globals_init, i915_globals_exit },
> { i915_mock_selftests, NULL },
> { i915_pmu_init, i915_pmu_exit },
> --
> 2.32.0
>
Re: [Intel-gfx] [PATCH 0/8] drm/i915: Migrate memory to SMEM when imported cross-device (v8)
On Mon, 26 Jul 2021 at 16:11, Jason Ekstrand wrote: > > On Mon, Jul 26, 2021 at 3:12 AM Matthew Auld > wrote: > > > > On Fri, 23 Jul 2021 at 18:21, Jason Ekstrand wrote: > > > > > > This patch series fixes an issue with discrete graphics on Intel where we > > > allowed dma-buf import while leaving the object in local memory. This > > > breaks down pretty badly if the import happened on a different physical > > > device. > > > > > > v7: > > > - Drop "drm/i915/gem/ttm: Place new BOs in the requested region" > > > - Add a new "drm/i915/gem: Call i915_gem_flush_free_objects() in > > > i915_gem_dumb_create()" > > > - Misc. review feedback from Matthew Auld > > > v8: > > > - Misc. review feedback from Matthew Auld > > > v9: > > > - Replace the i915/ttm patch with two that are hopefully more correct > > > > > > Jason Ekstrand (6): > > > drm/i915/gem: Check object_can_migrate from object_migrate > > > drm/i915/gem: Refactor placement setup for i915_gem_object_create* > > > (v2) > > > drm/i915/gem: Call i915_gem_flush_free_objects() in > > > i915_gem_dumb_create() > > > drm/i915/gem: Unify user object creation (v3) > > > drm/i915/gem/ttm: Only call __i915_gem_object_set_pages if needed > > > drm/i915/gem: Always call obj->ops->migrate unless can_migrate fails > > > > > > Thomas Hellström (2): > > > drm/i915/gem: Correct the locking and pin pattern for dma-buf (v8) > > > drm/i915/gem: Migrate to system at dma-buf attach time (v7) > > > > Should I push the series? > > Yes, please. Do we have a solid testing plan for things like this > that touch discrete? I tested with mesa+glxgears on my DG1 but > haven't run anything more stressful. I think all we really have are the migration related selftests, and CI is not even running them on DG1 due to other breakage. Assuming you ran these locally, I think we just merge the series? > > --Jason > > > > > > > > drivers/gpu/drm/i915/gem/i915_gem_create.c| 177 > > > drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c| 58 -- > > > drivers/gpu/drm/i915/gem/i915_gem_object.c| 20 +- > > > drivers/gpu/drm/i915/gem/i915_gem_object.h| 4 + > > > drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 13 +- > > > .../drm/i915/gem/selftests/i915_gem_dmabuf.c | 190 +- > > > .../drm/i915/gem/selftests/i915_gem_migrate.c | 15 -- > > > 7 files changed, 341 insertions(+), 136 deletions(-) > > > > > > -- > > > 2.31.1 > > > > > > ___ > > > Intel-gfx mailing list > > > intel-...@lists.freedesktop.org > > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 04/10] drm/i915: move intel_context slab to direct module init/exit
On Mon, Jul 26, 2021 at 3:35 AM Tvrtko Ursulin
wrote:
>
>
> On 23/07/2021 20:29, Daniel Vetter wrote:
> > With the global kmem_cache shrink infrastructure gone there's nothing
> > special and we can convert them over.
> >
> > I'm doing this split up into each patch because there's quite a bit of
> > noise with removing the static global.slab_ce to just a
> > slab_ce.
> >
> > Cc: Jason Ekstrand
> > Signed-off-by: Daniel Vetter
> > ---
> > drivers/gpu/drm/i915/gt/intel_context.c | 25 -
> > drivers/gpu/drm/i915/gt/intel_context.h | 3 +++
> > drivers/gpu/drm/i915/i915_globals.c | 2 --
> > drivers/gpu/drm/i915/i915_globals.h | 1 -
> > drivers/gpu/drm/i915/i915_pci.c | 2 ++
> > 5 files changed, 13 insertions(+), 20 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
> > b/drivers/gpu/drm/i915/gt/intel_context.c
> > index baa05fddd690..283382549a6f 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_context.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_context.c
> > @@ -7,7 +7,6 @@
> > #include "gem/i915_gem_pm.h"
> >
> > #include "i915_drv.h"
> > -#include "i915_globals.h"
> > #include "i915_trace.h"
> >
> > #include "intel_context.h"
> > @@ -15,14 +14,11 @@
> > #include "intel_engine_pm.h"
> > #include "intel_ring.h"
> >
> > -static struct i915_global_context {
> > - struct i915_global base;
> > - struct kmem_cache *slab_ce;
> > -} global;
> > +struct kmem_cache *slab_ce;
Static? With that,
Reviewed-by: Jason Ekstrand
> >
> > static struct intel_context *intel_context_alloc(void)
> > {
> > - return kmem_cache_zalloc(global.slab_ce, GFP_KERNEL);
> > + return kmem_cache_zalloc(slab_ce, GFP_KERNEL);
> > }
> >
> > static void rcu_context_free(struct rcu_head *rcu)
> > @@ -30,7 +26,7 @@ static void rcu_context_free(struct rcu_head *rcu)
> > struct intel_context *ce = container_of(rcu, typeof(*ce), rcu);
> >
> > trace_intel_context_free(ce);
> > - kmem_cache_free(global.slab_ce, ce);
> > + kmem_cache_free(slab_ce, ce);
> > }
> >
> > void intel_context_free(struct intel_context *ce)
> > @@ -410,22 +406,17 @@ void intel_context_fini(struct intel_context *ce)
> > i915_active_fini(&ce->active);
> > }
> >
> > -static void i915_global_context_exit(void)
> > +void i915_context_module_exit(void)
> > {
> > - kmem_cache_destroy(global.slab_ce);
> > + kmem_cache_destroy(slab_ce);
> > }
> >
> > -static struct i915_global_context global = { {
> > - .exit = i915_global_context_exit,
> > -} };
> > -
> > -int __init i915_global_context_init(void)
> > +int __init i915_context_module_init(void)
> > {
> > - global.slab_ce = KMEM_CACHE(intel_context, SLAB_HWCACHE_ALIGN);
> > - if (!global.slab_ce)
> > + slab_ce = KMEM_CACHE(intel_context, SLAB_HWCACHE_ALIGN);
> > + if (!slab_ce)
> > return -ENOMEM;
> >
> > - i915_global_register(&global.base);
> > return 0;
> > }
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_context.h
> > b/drivers/gpu/drm/i915/gt/intel_context.h
> > index 974ef85320c2..a0ca82e3c40d 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_context.h
> > +++ b/drivers/gpu/drm/i915/gt/intel_context.h
> > @@ -30,6 +30,9 @@ void intel_context_init(struct intel_context *ce,
> > struct intel_engine_cs *engine);
> > void intel_context_fini(struct intel_context *ce);
> >
> > +void i915_context_module_exit(void);
> > +int i915_context_module_init(void);
> > +
> > struct intel_context *
> > intel_context_create(struct intel_engine_cs *engine);
> >
> > diff --git a/drivers/gpu/drm/i915/i915_globals.c
> > b/drivers/gpu/drm/i915/i915_globals.c
> > index 3de7cf22ec76..d36eb7dc40aa 100644
> > --- a/drivers/gpu/drm/i915/i915_globals.c
> > +++ b/drivers/gpu/drm/i915/i915_globals.c
> > @@ -7,7 +7,6 @@
> > #include
> > #include
> >
> > -#include "gem/i915_gem_context.h"
> > #include "gem/i915_gem_object.h"
> > #include "i915_globals.h"
> > #include "i915_request.h"
> > @@ -32,7 +31,6 @@ static void __i915_globals_cleanup(void)
> > }
> >
> > static __initconst int (* const initfn[])(void) = {
> > - i915_global_context_init,
> > i915_global_gem_context_init,
> > i915_global_objects_init,
> > i915_global_request_init,
> > diff --git a/drivers/gpu/drm/i915/i915_globals.h
> > b/drivers/gpu/drm/i915/i915_globals.h
> > index d80901ba75e3..60daa738a188 100644
> > --- a/drivers/gpu/drm/i915/i915_globals.h
> > +++ b/drivers/gpu/drm/i915/i915_globals.h
> > @@ -23,7 +23,6 @@ int i915_globals_init(void);
> > void i915_globals_exit(void);
> >
> > /* constructors */
> > -int i915_global_context_init(void);
> > int i915_global_gem_context_init(void);
> > int i915_global_objects_init(void);
> > int i915_global_request_init(void);
> > diff --git a/drivers/gpu/drm/i915/i915_pci.c
> > b/drivers/gpu/drm/i915/i915_pci.c
> > index f9527269e30a..266618157775 100644
> > --- a/drivers/gpu/
Re: [Intel-gfx] [PATCH 0/8] drm/i915: Migrate memory to SMEM when imported cross-device (v8)
On Mon, Jul 26, 2021 at 10:29 AM Matthew Auld wrote: > > On Mon, 26 Jul 2021 at 16:11, Jason Ekstrand wrote: > > > > On Mon, Jul 26, 2021 at 3:12 AM Matthew Auld > > wrote: > > > > > > On Fri, 23 Jul 2021 at 18:21, Jason Ekstrand wrote: > > > > > > > > This patch series fixes an issue with discrete graphics on Intel where > > > > we > > > > allowed dma-buf import while leaving the object in local memory. This > > > > breaks down pretty badly if the import happened on a different physical > > > > device. > > > > > > > > v7: > > > > - Drop "drm/i915/gem/ttm: Place new BOs in the requested region" > > > > - Add a new "drm/i915/gem: Call i915_gem_flush_free_objects() in > > > > i915_gem_dumb_create()" > > > > - Misc. review feedback from Matthew Auld > > > > v8: > > > > - Misc. review feedback from Matthew Auld > > > > v9: > > > > - Replace the i915/ttm patch with two that are hopefully more correct > > > > > > > > Jason Ekstrand (6): > > > > drm/i915/gem: Check object_can_migrate from object_migrate > > > > drm/i915/gem: Refactor placement setup for i915_gem_object_create* > > > > (v2) > > > > drm/i915/gem: Call i915_gem_flush_free_objects() in > > > > i915_gem_dumb_create() > > > > drm/i915/gem: Unify user object creation (v3) > > > > drm/i915/gem/ttm: Only call __i915_gem_object_set_pages if needed > > > > drm/i915/gem: Always call obj->ops->migrate unless can_migrate fails > > > > > > > > Thomas Hellström (2): > > > > drm/i915/gem: Correct the locking and pin pattern for dma-buf (v8) > > > > drm/i915/gem: Migrate to system at dma-buf attach time (v7) > > > > > > Should I push the series? > > > > Yes, please. Do we have a solid testing plan for things like this > > that touch discrete? I tested with mesa+glxgears on my DG1 but > > haven't run anything more stressful. > > I think all we really have are the migration related selftests, and CI > is not even running them on DG1 due to other breakage. Assuming you > ran these locally, I think we just merge the series? Works for me. Yes, I ran them on my TGL+DG1 box. I've also tested both GL and Vulkan PRIME support with the client running on DG1 and the compositor running on TGL with this series and everything works smooth. --Jason > > > > --Jason > > > > > > > > > > > > drivers/gpu/drm/i915/gem/i915_gem_create.c| 177 > > > > drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c| 58 -- > > > > drivers/gpu/drm/i915/gem/i915_gem_object.c| 20 +- > > > > drivers/gpu/drm/i915/gem/i915_gem_object.h| 4 + > > > > drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 13 +- > > > > .../drm/i915/gem/selftests/i915_gem_dmabuf.c | 190 +- > > > > .../drm/i915/gem/selftests/i915_gem_migrate.c | 15 -- > > > > 7 files changed, 341 insertions(+), 136 deletions(-) > > > > > > > > -- > > > > 2.31.1 > > > > > > > > ___ > > > > Intel-gfx mailing list > > > > intel-...@lists.freedesktop.org > > > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [PATCH 05/10] drm/i915: move gem_context slab to direct module init/exit
On Fri, Jul 23, 2021 at 2:29 PM Daniel Vetter wrote:
>
> With the global kmem_cache shrink infrastructure gone there's nothing
> special and we can convert them over.
>
> I'm doing this split up into each patch because there's quite a bit of
> noise with removing the static global.slab_luts to just a
> slab_luts.
>
> Cc: Jason Ekstrand
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/gem/i915_gem_context.c | 25 +++--
> drivers/gpu/drm/i915/gem/i915_gem_context.h | 3 +++
> drivers/gpu/drm/i915/i915_globals.c | 2 --
> drivers/gpu/drm/i915/i915_globals.h | 1 -
> drivers/gpu/drm/i915/i915_pci.c | 2 ++
> 5 files changed, 13 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> index 89ca401bf9ae..c17c28af1e57 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> @@ -79,25 +79,21 @@
> #include "gt/intel_ring.h"
>
> #include "i915_gem_context.h"
> -#include "i915_globals.h"
> #include "i915_trace.h"
> #include "i915_user_extensions.h"
>
> #define ALL_L3_SLICES(dev) (1 << NUM_L3_SLICES(dev)) - 1
>
> -static struct i915_global_gem_context {
> - struct i915_global base;
> - struct kmem_cache *slab_luts;
> -} global;
> +struct kmem_cache *slab_luts;
static.
With that,
Reviewed-by: Jason Ekstrand
> struct i915_lut_handle *i915_lut_handle_alloc(void)
> {
> - return kmem_cache_alloc(global.slab_luts, GFP_KERNEL);
> + return kmem_cache_alloc(slab_luts, GFP_KERNEL);
> }
>
> void i915_lut_handle_free(struct i915_lut_handle *lut)
> {
> - return kmem_cache_free(global.slab_luts, lut);
> + return kmem_cache_free(slab_luts, lut);
> }
>
> static void lut_close(struct i915_gem_context *ctx)
> @@ -2282,21 +2278,16 @@ i915_gem_engines_iter_next(struct
> i915_gem_engines_iter *it)
> #include "selftests/i915_gem_context.c"
> #endif
>
> -static void i915_global_gem_context_exit(void)
> +void i915_gem_context_module_exit(void)
> {
> - kmem_cache_destroy(global.slab_luts);
> + kmem_cache_destroy(slab_luts);
> }
>
> -static struct i915_global_gem_context global = { {
> - .exit = i915_global_gem_context_exit,
> -} };
> -
> -int __init i915_global_gem_context_init(void)
> +int __init i915_gem_context_module_init(void)
> {
> - global.slab_luts = KMEM_CACHE(i915_lut_handle, 0);
> - if (!global.slab_luts)
> + slab_luts = KMEM_CACHE(i915_lut_handle, 0);
> + if (!slab_luts)
> return -ENOMEM;
>
> - i915_global_register(&global.base);
> return 0;
> }
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.h
> b/drivers/gpu/drm/i915/gem/i915_gem_context.h
> index 20411db84914..18060536b0c2 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_context.h
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.h
> @@ -224,6 +224,9 @@ i915_gem_engines_iter_next(struct i915_gem_engines_iter
> *it);
> for (i915_gem_engines_iter_init(&(it), (engines)); \
> ((ce) = i915_gem_engines_iter_next(&(it)));)
>
> +void i915_gem_context_module_exit(void);
> +int i915_gem_context_module_init(void);
> +
> struct i915_lut_handle *i915_lut_handle_alloc(void);
> void i915_lut_handle_free(struct i915_lut_handle *lut);
>
> diff --git a/drivers/gpu/drm/i915/i915_globals.c
> b/drivers/gpu/drm/i915/i915_globals.c
> index d36eb7dc40aa..dbb3d81eeea7 100644
> --- a/drivers/gpu/drm/i915/i915_globals.c
> +++ b/drivers/gpu/drm/i915/i915_globals.c
> @@ -7,7 +7,6 @@
> #include
> #include
>
> -#include "gem/i915_gem_object.h"
> #include "i915_globals.h"
> #include "i915_request.h"
> #include "i915_scheduler.h"
> @@ -31,7 +30,6 @@ static void __i915_globals_cleanup(void)
> }
>
> static __initconst int (* const initfn[])(void) = {
> - i915_global_gem_context_init,
> i915_global_objects_init,
> i915_global_request_init,
> i915_global_scheduler_init,
> diff --git a/drivers/gpu/drm/i915/i915_globals.h
> b/drivers/gpu/drm/i915/i915_globals.h
> index 60daa738a188..f16752dbbdbf 100644
> --- a/drivers/gpu/drm/i915/i915_globals.h
> +++ b/drivers/gpu/drm/i915/i915_globals.h
> @@ -23,7 +23,6 @@ int i915_globals_init(void);
> void i915_globals_exit(void);
>
> /* constructors */
> -int i915_global_gem_context_init(void);
> int i915_global_objects_init(void);
> int i915_global_request_init(void);
> int i915_global_scheduler_init(void);
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index 266618157775..2b56e664d043 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -34,6 +34,7 @@
> #include "i915_buddy.h"
> #include "i915_drv.h"
> #include "gem/i915_gem_context.h"
> +#include "gem/i915_gem_object.h"
> #include "i915_perf.h"
> #include "i915_globals.h"
> #include "i915_selftest.h"
> @@ -1299,6 +1300,7 @@ static cons
Re: [PATCH 06/10] drm/i915: move gem_objects slab to direct module init/exit
On Fri, Jul 23, 2021 at 2:29 PM Daniel Vetter wrote:
>
> With the global kmem_cache shrink infrastructure gone there's nothing
> special and we can convert them over.
>
> I'm doing this split up into each patch because there's quite a bit of
> noise with removing the static global.slab_objects to just a
> slab_objects.
>
> Cc: Jason Ekstrand
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/gem/i915_gem_object.c | 26 +++---
> drivers/gpu/drm/i915/gem/i915_gem_object.h | 3 +++
> drivers/gpu/drm/i915/i915_globals.c| 1 -
> drivers/gpu/drm/i915/i915_globals.h| 1 -
> drivers/gpu/drm/i915/i915_pci.c| 1 +
> 5 files changed, 12 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
> b/drivers/gpu/drm/i915/gem/i915_gem_object.c
> index 5c21cff33199..53156250d283 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
> @@ -30,14 +30,10 @@
> #include "i915_gem_context.h"
> #include "i915_gem_mman.h"
> #include "i915_gem_object.h"
> -#include "i915_globals.h"
> #include "i915_memcpy.h"
> #include "i915_trace.h"
>
> -static struct i915_global_object {
> - struct i915_global base;
> - struct kmem_cache *slab_objects;
> -} global;
> +struct kmem_cache *slab_objects;
static
With that,
Reviewed-by: Jason Ekstrand
> static const struct drm_gem_object_funcs i915_gem_object_funcs;
>
> @@ -45,7 +41,7 @@ struct drm_i915_gem_object *i915_gem_object_alloc(void)
> {
> struct drm_i915_gem_object *obj;
>
> - obj = kmem_cache_zalloc(global.slab_objects, GFP_KERNEL);
> + obj = kmem_cache_zalloc(slab_objects, GFP_KERNEL);
> if (!obj)
> return NULL;
> obj->base.funcs = &i915_gem_object_funcs;
> @@ -55,7 +51,7 @@ struct drm_i915_gem_object *i915_gem_object_alloc(void)
>
> void i915_gem_object_free(struct drm_i915_gem_object *obj)
> {
> - return kmem_cache_free(global.slab_objects, obj);
> + return kmem_cache_free(slab_objects, obj);
> }
>
> void i915_gem_object_init(struct drm_i915_gem_object *obj,
> @@ -664,23 +660,17 @@ void i915_gem_init__objects(struct drm_i915_private
> *i915)
> INIT_WORK(&i915->mm.free_work, __i915_gem_free_work);
> }
>
> -static void i915_global_objects_exit(void)
> +void i915_objects_module_exit(void)
> {
> - kmem_cache_destroy(global.slab_objects);
> + kmem_cache_destroy(slab_objects);
> }
>
> -static struct i915_global_object global = { {
> - .exit = i915_global_objects_exit,
> -} };
> -
> -int __init i915_global_objects_init(void)
> +int __init i915_objects_module_init(void)
> {
> - global.slab_objects =
> - KMEM_CACHE(drm_i915_gem_object, SLAB_HWCACHE_ALIGN);
> - if (!global.slab_objects)
> + slab_objects = KMEM_CACHE(drm_i915_gem_object, SLAB_HWCACHE_ALIGN);
> + if (!slab_objects)
> return -ENOMEM;
>
> - i915_global_register(&global.base);
> return 0;
> }
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h
> b/drivers/gpu/drm/i915/gem/i915_gem_object.h
> index f3ede43282dc..6d8ea62a372f 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
> @@ -48,6 +48,9 @@ static inline bool i915_gem_object_size_2big(u64 size)
>
> void i915_gem_init__objects(struct drm_i915_private *i915);
>
> +void i915_objects_module_exit(void);
> +int i915_objects_module_init(void);
> +
> struct drm_i915_gem_object *i915_gem_object_alloc(void);
> void i915_gem_object_free(struct drm_i915_gem_object *obj);
>
> diff --git a/drivers/gpu/drm/i915/i915_globals.c
> b/drivers/gpu/drm/i915/i915_globals.c
> index dbb3d81eeea7..40a592fbc3e0 100644
> --- a/drivers/gpu/drm/i915/i915_globals.c
> +++ b/drivers/gpu/drm/i915/i915_globals.c
> @@ -30,7 +30,6 @@ static void __i915_globals_cleanup(void)
> }
>
> static __initconst int (* const initfn[])(void) = {
> - i915_global_objects_init,
> i915_global_request_init,
> i915_global_scheduler_init,
> i915_global_vma_init,
> diff --git a/drivers/gpu/drm/i915/i915_globals.h
> b/drivers/gpu/drm/i915/i915_globals.h
> index f16752dbbdbf..9734740708f4 100644
> --- a/drivers/gpu/drm/i915/i915_globals.h
> +++ b/drivers/gpu/drm/i915/i915_globals.h
> @@ -23,7 +23,6 @@ int i915_globals_init(void);
> void i915_globals_exit(void);
>
> /* constructors */
> -int i915_global_objects_init(void);
> int i915_global_request_init(void);
> int i915_global_scheduler_init(void);
> int i915_global_vma_init(void);
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index 2b56e664d043..2334eb3e9abb 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -1301,6 +1301,7 @@ static const struct {
> { i915_buddy_module_init, i915_buddy_module_exit },
> { i915_context_module_init, i915_context_module_exit }
Re: [Intel-gfx] [PATCH 04/10] drm/i915: move intel_context slab to direct module init/exit
On Mon, Jul 26, 2021 at 10:30 AM Jason Ekstrand wrote:
>
> On Mon, Jul 26, 2021 at 3:35 AM Tvrtko Ursulin
> wrote:
> >
> >
> > On 23/07/2021 20:29, Daniel Vetter wrote:
> > > With the global kmem_cache shrink infrastructure gone there's nothing
> > > special and we can convert them over.
> > >
> > > I'm doing this split up into each patch because there's quite a bit of
> > > noise with removing the static global.slab_ce to just a
> > > slab_ce.
> > >
> > > Cc: Jason Ekstrand
> > > Signed-off-by: Daniel Vetter
> > > ---
> > > drivers/gpu/drm/i915/gt/intel_context.c | 25 -
> > > drivers/gpu/drm/i915/gt/intel_context.h | 3 +++
> > > drivers/gpu/drm/i915/i915_globals.c | 2 --
> > > drivers/gpu/drm/i915/i915_globals.h | 1 -
> > > drivers/gpu/drm/i915/i915_pci.c | 2 ++
> > > 5 files changed, 13 insertions(+), 20 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
> > > b/drivers/gpu/drm/i915/gt/intel_context.c
> > > index baa05fddd690..283382549a6f 100644
> > > --- a/drivers/gpu/drm/i915/gt/intel_context.c
> > > +++ b/drivers/gpu/drm/i915/gt/intel_context.c
> > > @@ -7,7 +7,6 @@
> > > #include "gem/i915_gem_pm.h"
> > >
> > > #include "i915_drv.h"
> > > -#include "i915_globals.h"
> > > #include "i915_trace.h"
> > >
> > > #include "intel_context.h"
> > > @@ -15,14 +14,11 @@
> > > #include "intel_engine_pm.h"
> > > #include "intel_ring.h"
> > >
> > > -static struct i915_global_context {
> > > - struct i915_global base;
> > > - struct kmem_cache *slab_ce;
> > > -} global;
> > > +struct kmem_cache *slab_ce;
>
> Static? With that,
>
> Reviewed-by: Jason Ekstrand
>
> > >
> > > static struct intel_context *intel_context_alloc(void)
> > > {
> > > - return kmem_cache_zalloc(global.slab_ce, GFP_KERNEL);
> > > + return kmem_cache_zalloc(slab_ce, GFP_KERNEL);
> > > }
> > >
> > > static void rcu_context_free(struct rcu_head *rcu)
> > > @@ -30,7 +26,7 @@ static void rcu_context_free(struct rcu_head *rcu)
> > > struct intel_context *ce = container_of(rcu, typeof(*ce), rcu);
> > >
> > > trace_intel_context_free(ce);
> > > - kmem_cache_free(global.slab_ce, ce);
> > > + kmem_cache_free(slab_ce, ce);
> > > }
> > >
> > > void intel_context_free(struct intel_context *ce)
> > > @@ -410,22 +406,17 @@ void intel_context_fini(struct intel_context *ce)
> > > i915_active_fini(&ce->active);
> > > }
> > >
> > > -static void i915_global_context_exit(void)
> > > +void i915_context_module_exit(void)
> > > {
> > > - kmem_cache_destroy(global.slab_ce);
> > > + kmem_cache_destroy(slab_ce);
> > > }
> > >
> > > -static struct i915_global_context global = { {
> > > - .exit = i915_global_context_exit,
> > > -} };
> > > -
> > > -int __init i915_global_context_init(void)
> > > +int __init i915_context_module_init(void)
> > > {
> > > - global.slab_ce = KMEM_CACHE(intel_context, SLAB_HWCACHE_ALIGN);
> > > - if (!global.slab_ce)
> > > + slab_ce = KMEM_CACHE(intel_context, SLAB_HWCACHE_ALIGN);
> > > + if (!slab_ce)
> > > return -ENOMEM;
> > >
> > > - i915_global_register(&global.base);
> > > return 0;
> > > }
> > >
> > > diff --git a/drivers/gpu/drm/i915/gt/intel_context.h
> > > b/drivers/gpu/drm/i915/gt/intel_context.h
> > > index 974ef85320c2..a0ca82e3c40d 100644
> > > --- a/drivers/gpu/drm/i915/gt/intel_context.h
> > > +++ b/drivers/gpu/drm/i915/gt/intel_context.h
> > > @@ -30,6 +30,9 @@ void intel_context_init(struct intel_context *ce,
> > > struct intel_engine_cs *engine);
> > > void intel_context_fini(struct intel_context *ce);
> > >
> > > +void i915_context_module_exit(void);
> > > +int i915_context_module_init(void);
> > > +
> > > struct intel_context *
> > > intel_context_create(struct intel_engine_cs *engine);
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_globals.c
> > > b/drivers/gpu/drm/i915/i915_globals.c
> > > index 3de7cf22ec76..d36eb7dc40aa 100644
> > > --- a/drivers/gpu/drm/i915/i915_globals.c
> > > +++ b/drivers/gpu/drm/i915/i915_globals.c
> > > @@ -7,7 +7,6 @@
> > > #include
> > > #include
> > >
> > > -#include "gem/i915_gem_context.h"
> > > #include "gem/i915_gem_object.h"
> > > #include "i915_globals.h"
> > > #include "i915_request.h"
> > > @@ -32,7 +31,6 @@ static void __i915_globals_cleanup(void)
> > > }
> > >
> > > static __initconst int (* const initfn[])(void) = {
> > > - i915_global_context_init,
> > > i915_global_gem_context_init,
> > > i915_global_objects_init,
> > > i915_global_request_init,
> > > diff --git a/drivers/gpu/drm/i915/i915_globals.h
> > > b/drivers/gpu/drm/i915/i915_globals.h
> > > index d80901ba75e3..60daa738a188 100644
> > > --- a/drivers/gpu/drm/i915/i915_globals.h
> > > +++ b/drivers/gpu/drm/i915/i915_globals.h
> > > @@ -23,7 +23,6 @@ int i915_globals_init(void);
> > > void i915_globals_exit(void);
> > >
> > > /* construc
Re: [PATCH 07/10] drm/i915: move request slabs to direct module init/exit
On Fri, Jul 23, 2021 at 2:29 PM Daniel Vetter wrote:
>
> With the global kmem_cache shrink infrastructure gone there's nothing
> special and we can convert them over.
>
> I'm doing this split up into each patch because there's quite a bit of
> noise with removing the static global.slab_requests|execute_cbs to just a
> slab_requests|execute_cbs.
>
> Cc: Jason Ekstrand
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/i915_globals.c | 2 --
> drivers/gpu/drm/i915/i915_pci.c | 2 ++
> drivers/gpu/drm/i915/i915_request.c | 47 -
> drivers/gpu/drm/i915/i915_request.h | 3 ++
> 4 files changed, 24 insertions(+), 30 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_globals.c
> b/drivers/gpu/drm/i915/i915_globals.c
> index 40a592fbc3e0..8fffa8d93bc5 100644
> --- a/drivers/gpu/drm/i915/i915_globals.c
> +++ b/drivers/gpu/drm/i915/i915_globals.c
> @@ -8,7 +8,6 @@
> #include
>
> #include "i915_globals.h"
> -#include "i915_request.h"
> #include "i915_scheduler.h"
> #include "i915_vma.h"
>
> @@ -30,7 +29,6 @@ static void __i915_globals_cleanup(void)
> }
>
> static __initconst int (* const initfn[])(void) = {
> - i915_global_request_init,
> i915_global_scheduler_init,
> i915_global_vma_init,
> };
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index 2334eb3e9abb..bb2bd12fb8c2 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -35,6 +35,7 @@
> #include "i915_drv.h"
> #include "gem/i915_gem_context.h"
> #include "gem/i915_gem_object.h"
> +#include "i915_request.h"
> #include "i915_perf.h"
> #include "i915_globals.h"
> #include "i915_selftest.h"
> @@ -1302,6 +1303,7 @@ static const struct {
> { i915_context_module_init, i915_context_module_exit },
> { i915_gem_context_module_init, i915_gem_context_module_exit },
> { i915_objects_module_init, i915_objects_module_exit },
> + { i915_request_module_init, i915_request_module_exit },
> { i915_globals_init, i915_globals_exit },
> { i915_mock_selftests, NULL },
> { i915_pmu_init, i915_pmu_exit },
> diff --git a/drivers/gpu/drm/i915/i915_request.c
> b/drivers/gpu/drm/i915/i915_request.c
> index 6594cb2f8ebd..69152369ea00 100644
> --- a/drivers/gpu/drm/i915/i915_request.c
> +++ b/drivers/gpu/drm/i915/i915_request.c
> @@ -42,7 +42,6 @@
>
> #include "i915_active.h"
> #include "i915_drv.h"
> -#include "i915_globals.h"
> #include "i915_trace.h"
> #include "intel_pm.h"
>
> @@ -52,11 +51,8 @@ struct execute_cb {
> struct i915_request *signal;
> };
>
> -static struct i915_global_request {
> - struct i915_global base;
> - struct kmem_cache *slab_requests;
> - struct kmem_cache *slab_execute_cbs;
> -} global;
> +struct kmem_cache *slab_requests;
static
> +struct kmem_cache *slab_execute_cbs;
static
Am I tired of typing this? Yes, I am! Will I keep typing it? Probably. :-P
>
> static const char *i915_fence_get_driver_name(struct dma_fence *fence)
> {
> @@ -107,7 +103,7 @@ static signed long i915_fence_wait(struct dma_fence
> *fence,
>
> struct kmem_cache *i915_request_slab_cache(void)
> {
> - return global.slab_requests;
> + return slab_requests;
> }
>
> static void i915_fence_release(struct dma_fence *fence)
> @@ -159,7 +155,7 @@ static void i915_fence_release(struct dma_fence *fence)
> !cmpxchg(&rq->engine->request_pool, NULL, rq))
> return;
>
> - kmem_cache_free(global.slab_requests, rq);
> + kmem_cache_free(slab_requests, rq);
> }
>
> const struct dma_fence_ops i915_fence_ops = {
> @@ -176,7 +172,7 @@ static void irq_execute_cb(struct irq_work *wrk)
> struct execute_cb *cb = container_of(wrk, typeof(*cb), work);
>
> i915_sw_fence_complete(cb->fence);
> - kmem_cache_free(global.slab_execute_cbs, cb);
> + kmem_cache_free(slab_execute_cbs, cb);
> }
>
> static __always_inline void
> @@ -514,7 +510,7 @@ __await_execution(struct i915_request *rq,
> if (i915_request_is_active(signal))
> return 0;
>
> - cb = kmem_cache_alloc(global.slab_execute_cbs, gfp);
> + cb = kmem_cache_alloc(slab_execute_cbs, gfp);
> if (!cb)
> return -ENOMEM;
>
> @@ -868,7 +864,7 @@ request_alloc_slow(struct intel_timeline *tl,
> rq = list_first_entry(&tl->requests, typeof(*rq), link);
> i915_request_retire(rq);
>
> - rq = kmem_cache_alloc(global.slab_requests,
> + rq = kmem_cache_alloc(slab_requests,
> gfp | __GFP_RETRY_MAYFAIL | __GFP_NOWARN);
> if (rq)
> return rq;
> @@ -881,7 +877,7 @@ request_alloc_slow(struct intel_timeline *tl,
> retire_requests(tl);
>
> out:
> - return kmem_cache_alloc(global.slab_requests, gfp);
> + return kmem_cache_alloc(slab_requests, gfp);
> }
>
> static void __i915_request_ctor(void *a
Re: [PATCH v5 02/15] mei: pxp: export pavp client to me client bus
On 7/26/2021 8:04 AM, Winkler, Tomas wrote:
From: Vitaly Lubart
Export PAVP client to work with i915 driver, for binding it uses kernel
component framework.
Signed-off-by: Vitaly Lubart
Signed-off-by: Tomas Winkler
Signed-off-by: Daniele Ceraolo Spurio
Reviewed-by: Rodrigo Vivi
---
drivers/misc/mei/Kconfig | 2 +
drivers/misc/mei/Makefile | 1 +
drivers/misc/mei/pxp/Kconfig | 13 ++
drivers/misc/mei/pxp/Makefile | 7 +
drivers/misc/mei/pxp/mei_pxp.c | 233
+
drivers/misc/mei/pxp/mei_pxp.h | 18 +++
6 files changed, 274 insertions(+)
create mode 100644 drivers/misc/mei/pxp/Kconfig create mode 100644
drivers/misc/mei/pxp/Makefile create mode 100644
drivers/misc/mei/pxp/mei_pxp.c create mode 100644
drivers/misc/mei/pxp/mei_pxp.h
diff --git a/drivers/misc/mei/Kconfig b/drivers/misc/mei/Kconfig index
f5fd5b786607..0e0bcd0da852 100644
--- a/drivers/misc/mei/Kconfig
+++ b/drivers/misc/mei/Kconfig
@@ -47,3 +47,5 @@ config INTEL_MEI_TXE
Intel Bay Trail
source "drivers/misc/mei/hdcp/Kconfig"
+source "drivers/misc/mei/pxp/Kconfig"
+
diff --git a/drivers/misc/mei/Makefile b/drivers/misc/mei/Makefile index
f1c76f7ee804..d8e5165917f2 100644
--- a/drivers/misc/mei/Makefile
+++ b/drivers/misc/mei/Makefile
@@ -26,3 +26,4 @@ mei-$(CONFIG_EVENT_TRACING) += mei-trace.o
CFLAGS_mei-trace.o = -I$(src)
obj-$(CONFIG_INTEL_MEI_HDCP) += hdcp/
+obj-$(CONFIG_INTEL_MEI_PXP) += pxp/
diff --git a/drivers/misc/mei/pxp/Kconfig b/drivers/misc/mei/pxp/Kconfig
new file mode 100644 index ..4029b96afc04
--- /dev/null
+++ b/drivers/misc/mei/pxp/Kconfig
@@ -0,0 +1,13 @@
+
+# SPDX-License-Identifier: GPL-2.0
+# Copyright (c) 2020, Intel Corporation. All rights reserved.
2020-2021
ok
+#
+config INTEL_MEI_PXP
+tristate "Intel PXP services of ME Interface"
+select INTEL_MEI_ME
+depends on DRM_I915
+help
+ MEI Support for PXP Services on Intel platforms.
+
+ Enables the ME FW services required for PXP support through
+ I915 display driver of Intel.
diff --git a/drivers/misc/mei/pxp/Makefile b/drivers/misc/mei/pxp/Makefile
new file mode 100644 index ..0329950d5794
--- /dev/null
+++ b/drivers/misc/mei/pxp/Makefile
@@ -0,0 +1,7 @@
+# SPDX-License-Identifier: GPL-2.0
+#
+# Copyright (c) 2020, Intel Corporation. All rights reserved.
+#
+# Makefile - PXP client driver for Intel MEI Bus Driver.
+
+obj-$(CONFIG_INTEL_MEI_PXP) += mei_pxp.o
diff --git a/drivers/misc/mei/pxp/mei_pxp.c
b/drivers/misc/mei/pxp/mei_pxp.c new file mode 100644 index
..cacfbedb640a
--- /dev/null
+++ b/drivers/misc/mei/pxp/mei_pxp.c
@@ -0,0 +1,233 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright © 2020 Intel Corporation
+ */
+
+/**
+ * DOC: MEI_PXP Client Driver
+ *
+ * The mei_pxp driver acts as a translation layer between PXP
+ * protocol implementer (I915) and ME FW by translating PXP
+ * negotiation messages to ME FW command payloads and vice versa.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "mei_pxp.h"
+
+/**
+ * mei_pxp_send_message() - Sends a PXP message to ME FW.
+ * @dev: device corresponding to the mei_cl_device
+ * @message: a message buffer to send
+ * @size: size of the message
+ * Return: 0 on Success, <0 on Failure
+ */
+static int
+mei_pxp_send_message(struct device *dev, const void *message, size_t
+size) {
+struct mei_cl_device *cldev;
+ssize_t byte;
+
+if (!dev || !message)
+return -EINVAL;
+
+cldev = to_mei_cl_device(dev);
+
+/* temporary drop const qualifier till the API is fixed */
+byte = mei_cldev_send(cldev, (u8 *)message, size);
+if (byte < 0) {
+dev_dbg(dev, "mei_cldev_send failed. %zd\n", byte);
+return byte;
+}
+
+return 0;
+}
+
+/**
+ * mei_pxp_receive_message() - Receives a PXP message from ME FW.
+ * @dev: device corresponding to the mei_cl_device
+ * @buffer: a message buffer to contain the received message
+ * @size: size of the buffer
+ * Return: bytes sent on Success, <0 on Failure */ static int
+mei_pxp_receive_message(struct device *dev, void *buffer, size_t size)
+{
+struct mei_cl_device *cldev;
+ssize_t byte;
+
+if (!dev || !buffer)
+return -EINVAL;
+
+cldev = to_mei_cl_device(dev);
+
+byte = mei_cldev_recv(cldev, buffer, size);
+if (byte < 0) {
+dev_dbg(dev, "mei_cldev_recv failed. %zd\n", byte);
+return byte;
+}
+
+return byte;
+}
+
+static const struct i915_pxp_component_ops mei_pxp_ops = {
+.owner = THIS_MODULE,
+.send = mei_pxp_send_message,
+.recv = mei_pxp_receive_message,
+};
+
+static int mei_component_master_bind(struct device *dev) {
+struct mei_cl_device *cldev = to_mei_cl_device(dev);
+struct i915_pxp_component *comp_master =
mei_cldev_get_drvdata(cldev);
+int ret;
+
+dev_dbg(dev, "%s\n", __func__);
Pleased drop those __func__, as ftrace can be used
ok
+comp_master->ops = &mei_pxp_ops;
+comp_master->tee_dev = dev;
+ret = component_bind_all(dev, comp_master);
+if (ret < 0)
+return ret;
+
+return 0;
+}
+
+static void mei_com
Re: [PATCH 08/10] drm/i915: move scheduler slabs to direct module init/exit
On Fri, Jul 23, 2021 at 2:29 PM Daniel Vetter wrote:
>
> With the global kmem_cache shrink infrastructure gone there's nothing
> special and we can convert them over.
>
> I'm doing this split up into each patch because there's quite a bit of
> noise with removing the static global.slab_dependencies|priorities to just a
> slab_dependencies|priorities.
>
> Cc: Jason Ekstrand
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/i915_globals.c | 2 --
> drivers/gpu/drm/i915/i915_globals.h | 2 --
> drivers/gpu/drm/i915/i915_pci.c | 2 ++
> drivers/gpu/drm/i915/i915_scheduler.c | 39 +++
> drivers/gpu/drm/i915/i915_scheduler.h | 3 +++
> 5 files changed, 20 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_globals.c
> b/drivers/gpu/drm/i915/i915_globals.c
> index 8fffa8d93bc5..8923589057ab 100644
> --- a/drivers/gpu/drm/i915/i915_globals.c
> +++ b/drivers/gpu/drm/i915/i915_globals.c
> @@ -8,7 +8,6 @@
> #include
>
> #include "i915_globals.h"
> -#include "i915_scheduler.h"
> #include "i915_vma.h"
>
> static LIST_HEAD(globals);
> @@ -29,7 +28,6 @@ static void __i915_globals_cleanup(void)
> }
>
> static __initconst int (* const initfn[])(void) = {
> - i915_global_scheduler_init,
> i915_global_vma_init,
> };
>
> diff --git a/drivers/gpu/drm/i915/i915_globals.h
> b/drivers/gpu/drm/i915/i915_globals.h
> index 9734740708f4..7a57bce1da05 100644
> --- a/drivers/gpu/drm/i915/i915_globals.h
> +++ b/drivers/gpu/drm/i915/i915_globals.h
> @@ -23,8 +23,6 @@ int i915_globals_init(void);
> void i915_globals_exit(void);
>
> /* constructors */
> -int i915_global_request_init(void);
> -int i915_global_scheduler_init(void);
> int i915_global_vma_init(void);
>
> #endif /* _I915_GLOBALS_H_ */
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index bb2bd12fb8c2..a44318519977 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -39,6 +39,7 @@
> #include "i915_perf.h"
> #include "i915_globals.h"
> #include "i915_selftest.h"
> +#include "i915_scheduler.h"
>
> #define PLATFORM(x) .platform = (x)
> #define GEN(x) \
> @@ -1304,6 +1305,7 @@ static const struct {
> { i915_gem_context_module_init, i915_gem_context_module_exit },
> { i915_objects_module_init, i915_objects_module_exit },
> { i915_request_module_init, i915_request_module_exit },
> + { i915_scheduler_module_init, i915_scheduler_module_exit },
> { i915_globals_init, i915_globals_exit },
> { i915_mock_selftests, NULL },
> { i915_pmu_init, i915_pmu_exit },
> diff --git a/drivers/gpu/drm/i915/i915_scheduler.c
> b/drivers/gpu/drm/i915/i915_scheduler.c
> index 561c649e59f7..02d90d239ff5 100644
> --- a/drivers/gpu/drm/i915/i915_scheduler.c
> +++ b/drivers/gpu/drm/i915/i915_scheduler.c
> @@ -7,15 +7,11 @@
> #include
>
> #include "i915_drv.h"
> -#include "i915_globals.h"
> #include "i915_request.h"
> #include "i915_scheduler.h"
>
> -static struct i915_global_scheduler {
> - struct i915_global base;
> - struct kmem_cache *slab_dependencies;
> - struct kmem_cache *slab_priorities;
> -} global;
> +struct kmem_cache *slab_dependencies;
static
> +struct kmem_cache *slab_priorities;
static
>
> static DEFINE_SPINLOCK(schedule_lock);
>
> @@ -93,7 +89,7 @@ i915_sched_lookup_priolist(struct i915_sched_engine
> *sched_engine, int prio)
> if (prio == I915_PRIORITY_NORMAL) {
> p = &sched_engine->default_priolist;
> } else {
> - p = kmem_cache_alloc(global.slab_priorities, GFP_ATOMIC);
> + p = kmem_cache_alloc(slab_priorities, GFP_ATOMIC);
> /* Convert an allocation failure to a priority bump */
> if (unlikely(!p)) {
> prio = I915_PRIORITY_NORMAL; /* recurses just once */
> @@ -122,7 +118,7 @@ i915_sched_lookup_priolist(struct i915_sched_engine
> *sched_engine, int prio)
>
> void __i915_priolist_free(struct i915_priolist *p)
> {
> - kmem_cache_free(global.slab_priorities, p);
> + kmem_cache_free(slab_priorities, p);
> }
>
> struct sched_cache {
> @@ -313,13 +309,13 @@ void i915_sched_node_reinit(struct i915_sched_node
> *node)
> static struct i915_dependency *
> i915_dependency_alloc(void)
> {
> - return kmem_cache_alloc(global.slab_dependencies, GFP_KERNEL);
> + return kmem_cache_alloc(slab_dependencies, GFP_KERNEL);
> }
>
> static void
> i915_dependency_free(struct i915_dependency *dep)
> {
> - kmem_cache_free(global.slab_dependencies, dep);
> + kmem_cache_free(slab_dependencies, dep);
> }
>
> bool __i915_sched_node_add_dependency(struct i915_sched_node *node,
> @@ -475,32 +471,27 @@ i915_sched_engine_create(unsigned int subclass)
> return sched_engine;
> }
>
> -static void i915_global_scheduler_exit(void)
> +void i915_scheduler_module_exit(void)
> {
> - kmem_cache_
Re: [PATCH 09/10] drm/i915: move vma slab to direct module init/exit
On Fri, Jul 23, 2021 at 2:29 PM Daniel Vetter wrote:
>
> With the global kmem_cache shrink infrastructure gone there's nothing
> special and we can convert them over.
>
> I'm doing this split up into each patch because there's quite a bit of
> noise with removing the static global.slab_vmas to just a
> slab_vmas.
>
> We have to keep i915_drv.h include in i915_globals otherwise there's
> nothing anymore that pulls in GEM_BUG_ON.
>
> Cc: Jason Ekstrand
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/i915_globals.c | 3 +--
> drivers/gpu/drm/i915/i915_globals.h | 3 ---
> drivers/gpu/drm/i915/i915_pci.c | 2 ++
> drivers/gpu/drm/i915/i915_vma.c | 25 -
> drivers/gpu/drm/i915/i915_vma.h | 3 +++
> 5 files changed, 14 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_globals.c
> b/drivers/gpu/drm/i915/i915_globals.c
> index 8923589057ab..04979789e7be 100644
> --- a/drivers/gpu/drm/i915/i915_globals.c
> +++ b/drivers/gpu/drm/i915/i915_globals.c
> @@ -8,7 +8,7 @@
> #include
>
> #include "i915_globals.h"
> -#include "i915_vma.h"
> +#include "i915_drv.h"
>
> static LIST_HEAD(globals);
>
> @@ -28,7 +28,6 @@ static void __i915_globals_cleanup(void)
> }
>
> static __initconst int (* const initfn[])(void) = {
> - i915_global_vma_init,
> };
>
> int __init i915_globals_init(void)
> diff --git a/drivers/gpu/drm/i915/i915_globals.h
> b/drivers/gpu/drm/i915/i915_globals.h
> index 7a57bce1da05..57d2998bba45 100644
> --- a/drivers/gpu/drm/i915/i915_globals.h
> +++ b/drivers/gpu/drm/i915/i915_globals.h
> @@ -22,7 +22,4 @@ void i915_global_register(struct i915_global *global);
> int i915_globals_init(void);
> void i915_globals_exit(void);
>
> -/* constructors */
> -int i915_global_vma_init(void);
> -
> #endif /* _I915_GLOBALS_H_ */
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index a44318519977..0affcf33a211 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -40,6 +40,7 @@
> #include "i915_globals.h"
> #include "i915_selftest.h"
> #include "i915_scheduler.h"
> +#include "i915_vma.h"
>
> #define PLATFORM(x) .platform = (x)
> #define GEN(x) \
> @@ -1306,6 +1307,7 @@ static const struct {
> { i915_objects_module_init, i915_objects_module_exit },
> { i915_request_module_init, i915_request_module_exit },
> { i915_scheduler_module_init, i915_scheduler_module_exit },
> + { i915_vma_module_init, i915_vma_module_exit },
> { i915_globals_init, i915_globals_exit },
> { i915_mock_selftests, NULL },
> { i915_pmu_init, i915_pmu_exit },
> diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
> index 09a7c47926f7..d094e2016b93 100644
> --- a/drivers/gpu/drm/i915/i915_vma.c
> +++ b/drivers/gpu/drm/i915/i915_vma.c
> @@ -34,24 +34,20 @@
> #include "gt/intel_gt_requests.h"
>
> #include "i915_drv.h"
> -#include "i915_globals.h"
> #include "i915_sw_fence_work.h"
> #include "i915_trace.h"
> #include "i915_vma.h"
>
> -static struct i915_global_vma {
> - struct i915_global base;
> - struct kmem_cache *slab_vmas;
> -} global;
> +struct kmem_cache *slab_vmas;
static. With that,
Reviewed-by: Jason Ekstrand
>
> struct i915_vma *i915_vma_alloc(void)
> {
> - return kmem_cache_zalloc(global.slab_vmas, GFP_KERNEL);
> + return kmem_cache_zalloc(slab_vmas, GFP_KERNEL);
> }
>
> void i915_vma_free(struct i915_vma *vma)
> {
> - return kmem_cache_free(global.slab_vmas, vma);
> + return kmem_cache_free(slab_vmas, vma);
> }
>
> #if IS_ENABLED(CONFIG_DRM_I915_ERRLOG_GEM) && IS_ENABLED(CONFIG_DRM_DEBUG_MM)
> @@ -1414,21 +1410,16 @@ void i915_vma_make_purgeable(struct i915_vma *vma)
> #include "selftests/i915_vma.c"
> #endif
>
> -static void i915_global_vma_exit(void)
> +void i915_vma_module_exit(void)
> {
> - kmem_cache_destroy(global.slab_vmas);
> + kmem_cache_destroy(slab_vmas);
> }
>
> -static struct i915_global_vma global = { {
> - .exit = i915_global_vma_exit,
> -} };
> -
> -int __init i915_global_vma_init(void)
> +int __init i915_vma_module_init(void)
> {
> - global.slab_vmas = KMEM_CACHE(i915_vma, SLAB_HWCACHE_ALIGN);
> - if (!global.slab_vmas)
> + slab_vmas = KMEM_CACHE(i915_vma, SLAB_HWCACHE_ALIGN);
> + if (!slab_vmas)
> return -ENOMEM;
>
> - i915_global_register(&global.base);
> return 0;
> }
> diff --git a/drivers/gpu/drm/i915/i915_vma.h b/drivers/gpu/drm/i915/i915_vma.h
> index eca452a9851f..ed69f66c7ab0 100644
> --- a/drivers/gpu/drm/i915/i915_vma.h
> +++ b/drivers/gpu/drm/i915/i915_vma.h
> @@ -426,4 +426,7 @@ static inline int i915_vma_sync(struct i915_vma *vma)
> return i915_active_wait(&vma->active);
> }
>
> +void i915_vma_module_exit(void);
> +int i915_vma_module_init(void);
> +
> #endif
> --
> 2.32.0
>
Re: [PATCH 10/10] drm/i915: Remove i915_globals
On Fri, Jul 23, 2021 at 2:29 PM Daniel Vetter wrote:
>
> No longer used.
>
> Cc: Jason Ekstrand
> Signed-off-by: Daniel Vetter
Reviewed-by: Jason Ekstrand
But, also, tvrtko is right that dumping all that stuff in i915_pci.c
isn't great. Mind typing a quick follow-on that moves i915_init/exit
to i915_drv.c?
--Jason
> ---
> drivers/gpu/drm/i915/Makefile | 1 -
> drivers/gpu/drm/i915/gt/intel_gt_pm.c | 1 -
> drivers/gpu/drm/i915/i915_globals.c | 53 ---
> drivers/gpu/drm/i915/i915_globals.h | 25 -
> drivers/gpu/drm/i915/i915_pci.c | 2 -
> 5 files changed, 82 deletions(-)
> delete mode 100644 drivers/gpu/drm/i915/i915_globals.c
> delete mode 100644 drivers/gpu/drm/i915/i915_globals.h
>
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index 10b3bb6207ba..9022dc638ed6 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -166,7 +166,6 @@ i915-y += \
> i915_gem_gtt.o \
> i915_gem_ww.o \
> i915_gem.o \
> - i915_globals.o \
> i915_query.o \
> i915_request.o \
> i915_scheduler.o \
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm.c
> b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
> index d86825437516..943c1d416ec0 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_pm.c
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
> @@ -6,7 +6,6 @@
> #include
>
> #include "i915_drv.h"
> -#include "i915_globals.h"
> #include "i915_params.h"
> #include "intel_context.h"
> #include "intel_engine_pm.h"
> diff --git a/drivers/gpu/drm/i915/i915_globals.c
> b/drivers/gpu/drm/i915/i915_globals.c
> deleted file mode 100644
> index 04979789e7be..
> --- a/drivers/gpu/drm/i915/i915_globals.c
> +++ /dev/null
> @@ -1,53 +0,0 @@
> -/*
> - * SPDX-License-Identifier: MIT
> - *
> - * Copyright © 2019 Intel Corporation
> - */
> -
> -#include
> -#include
> -
> -#include "i915_globals.h"
> -#include "i915_drv.h"
> -
> -static LIST_HEAD(globals);
> -
> -void __init i915_global_register(struct i915_global *global)
> -{
> - GEM_BUG_ON(!global->exit);
> -
> - list_add_tail(&global->link, &globals);
> -}
> -
> -static void __i915_globals_cleanup(void)
> -{
> - struct i915_global *global, *next;
> -
> - list_for_each_entry_safe_reverse(global, next, &globals, link)
> - global->exit();
> -}
> -
> -static __initconst int (* const initfn[])(void) = {
> -};
> -
> -int __init i915_globals_init(void)
> -{
> - int i;
> -
> - for (i = 0; i < ARRAY_SIZE(initfn); i++) {
> - int err;
> -
> - err = initfn[i]();
> - if (err) {
> - __i915_globals_cleanup();
> - return err;
> - }
> - }
> -
> - return 0;
> -}
> -
> -void i915_globals_exit(void)
> -{
> - __i915_globals_cleanup();
> -}
> diff --git a/drivers/gpu/drm/i915/i915_globals.h
> b/drivers/gpu/drm/i915/i915_globals.h
> deleted file mode 100644
> index 57d2998bba45..
> --- a/drivers/gpu/drm/i915/i915_globals.h
> +++ /dev/null
> @@ -1,25 +0,0 @@
> -/*
> - * SPDX-License-Identifier: MIT
> - *
> - * Copyright © 2019 Intel Corporation
> - */
> -
> -#ifndef _I915_GLOBALS_H_
> -#define _I915_GLOBALS_H_
> -
> -#include
> -
> -typedef void (*i915_global_func_t)(void);
> -
> -struct i915_global {
> - struct list_head link;
> -
> - i915_global_func_t exit;
> -};
> -
> -void i915_global_register(struct i915_global *global);
> -
> -int i915_globals_init(void);
> -void i915_globals_exit(void);
> -
> -#endif /* _I915_GLOBALS_H_ */
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index 0affcf33a211..ed72bcb58331 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -37,7 +37,6 @@
> #include "gem/i915_gem_object.h"
> #include "i915_request.h"
> #include "i915_perf.h"
> -#include "i915_globals.h"
> #include "i915_selftest.h"
> #include "i915_scheduler.h"
> #include "i915_vma.h"
> @@ -1308,7 +1307,6 @@ static const struct {
> { i915_request_module_init, i915_request_module_exit },
> { i915_scheduler_module_init, i915_scheduler_module_exit },
> { i915_vma_module_init, i915_vma_module_exit },
> - { i915_globals_init, i915_globals_exit },
> { i915_mock_selftests, NULL },
> { i915_pmu_init, i915_pmu_exit },
> { i915_register_pci_driver, i915_unregister_pci_driver },
> --
> 2.32.0
>
Re: [Intel-gfx] [PATCH 0/8] drm/i915: Migrate memory to SMEM when imported cross-device (v8)
On Mon, 26 Jul 2021 at 16:32, Jason Ekstrand wrote: > > On Mon, Jul 26, 2021 at 10:29 AM Matthew Auld > wrote: > > > > On Mon, 26 Jul 2021 at 16:11, Jason Ekstrand wrote: > > > > > > On Mon, Jul 26, 2021 at 3:12 AM Matthew Auld > > > wrote: > > > > > > > > On Fri, 23 Jul 2021 at 18:21, Jason Ekstrand > > > > wrote: > > > > > > > > > > This patch series fixes an issue with discrete graphics on Intel > > > > > where we > > > > > allowed dma-buf import while leaving the object in local memory. This > > > > > breaks down pretty badly if the import happened on a different > > > > > physical > > > > > device. > > > > > > > > > > v7: > > > > > - Drop "drm/i915/gem/ttm: Place new BOs in the requested region" > > > > > - Add a new "drm/i915/gem: Call i915_gem_flush_free_objects() in > > > > > i915_gem_dumb_create()" > > > > > - Misc. review feedback from Matthew Auld > > > > > v8: > > > > > - Misc. review feedback from Matthew Auld > > > > > v9: > > > > > - Replace the i915/ttm patch with two that are hopefully more correct > > > > > > > > > > Jason Ekstrand (6): > > > > > drm/i915/gem: Check object_can_migrate from object_migrate > > > > > drm/i915/gem: Refactor placement setup for i915_gem_object_create* > > > > > (v2) > > > > > drm/i915/gem: Call i915_gem_flush_free_objects() in > > > > > i915_gem_dumb_create() > > > > > drm/i915/gem: Unify user object creation (v3) > > > > > drm/i915/gem/ttm: Only call __i915_gem_object_set_pages if needed > > > > > drm/i915/gem: Always call obj->ops->migrate unless can_migrate fails > > > > > > > > > > Thomas Hellström (2): > > > > > drm/i915/gem: Correct the locking and pin pattern for dma-buf (v8) > > > > > drm/i915/gem: Migrate to system at dma-buf attach time (v7) > > > > > > > > Should I push the series? > > > > > > Yes, please. Do we have a solid testing plan for things like this > > > that touch discrete? I tested with mesa+glxgears on my DG1 but > > > haven't run anything more stressful. > > > > I think all we really have are the migration related selftests, and CI > > is not even running them on DG1 due to other breakage. Assuming you > > ran these locally, I think we just merge the series? > > Works for me. Yes, I ran them on my TGL+DG1 box. I've also tested > both GL and Vulkan PRIME support with the client running on DG1 and > the compositor running on TGL with this series and everything works > smooth. And pushed to drm-intel-gt-next. > > --Jason > > > > > > > > --Jason > > > > > > > > > > > > > > > > drivers/gpu/drm/i915/gem/i915_gem_create.c| 177 > > > > > drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c| 58 -- > > > > > drivers/gpu/drm/i915/gem/i915_gem_object.c| 20 +- > > > > > drivers/gpu/drm/i915/gem/i915_gem_object.h| 4 + > > > > > drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 13 +- > > > > > .../drm/i915/gem/selftests/i915_gem_dmabuf.c | 190 > > > > > +- > > > > > .../drm/i915/gem/selftests/i915_gem_migrate.c | 15 -- > > > > > 7 files changed, 341 insertions(+), 136 deletions(-) > > > > > > > > > > -- > > > > > 2.31.1 > > > > > > > > > > ___ > > > > > Intel-gfx mailing list > > > > > intel-...@lists.freedesktop.org > > > > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 01/33] drm/i915/guc: GuC virtual engines
On 7/24/2021 4:13 PM, Matthew Brost wrote:
On Fri, Jul 23, 2021 at 05:47:45PM -0700, Daniele Ceraolo Spurio wrote:
On 7/22/2021 4:53 PM, Matthew Brost wrote:
Implement GuC virtual engines. Rather simple implementation, basically
just allocate an engine, setup context enter / exit function to virtual
engine specific functions, set all other variables / functions to guc
versions, and set the engine mask to that of all the siblings.
v2: Update to work with proto-ctx
v3:
(Daniele)
- Drop include, add comment to intel_virtual_engine_has_heartbeat
Cc: Daniele Ceraolo Spurio
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 8 +-
drivers/gpu/drm/i915/gt/intel_context_types.h | 6 +
drivers/gpu/drm/i915/gt/intel_engine.h| 30 ++-
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 14 +
.../drm/i915/gt/intel_execlists_submission.c | 29 ++-
.../drm/i915/gt/intel_execlists_submission.h | 4 -
drivers/gpu/drm/i915/gt/selftest_execlists.c | 12 +-
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 244 +-
.../gpu/drm/i915/gt/uc/intel_guc_submission.h | 2 +
9 files changed, 313 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 89ca401bf9ae..bc52eeed782a 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -74,7 +74,6 @@
#include "gt/intel_context_param.h"
#include "gt/intel_engine_heartbeat.h"
#include "gt/intel_engine_user.h"
-#include "gt/intel_execlists_submission.h" /* virtual_engine */
#include "gt/intel_gpu_commands.h"
#include "gt/intel_ring.h"
@@ -363,9 +362,6 @@ set_proto_ctx_engines_balance(struct i915_user_extension
__user *base,
if (!HAS_EXECLISTS(i915))
return -ENODEV;
- if (intel_uc_uses_guc_submission(&i915->gt.uc))
- return -ENODEV; /* not implement yet */
-
if (get_user(idx, &ext->engine_index))
return -EFAULT;
@@ -950,8 +946,8 @@ static struct i915_gem_engines *user_engines(struct
i915_gem_context *ctx,
break;
case I915_GEM_ENGINE_TYPE_BALANCED:
- ce = intel_execlists_create_virtual(pe[n].siblings,
- pe[n].num_siblings);
+ ce = intel_engine_create_virtual(pe[n].siblings,
+pe[n].num_siblings);
break;
case I915_GEM_ENGINE_TYPE_INVALID:
diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h
b/drivers/gpu/drm/i915/gt/intel_context_types.h
index 4a5518d295c2..542c98418771 100644
--- a/drivers/gpu/drm/i915/gt/intel_context_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
@@ -47,6 +47,12 @@ struct intel_context_ops {
void (*reset)(struct intel_context *ce);
void (*destroy)(struct kref *kref);
+
+ /* virtual engine/context interface */
+ struct intel_context *(*create_virtual)(struct intel_engine_cs **engine,
+ unsigned int count);
+ struct intel_engine_cs *(*get_sibling)(struct intel_engine_cs *engine,
+ unsigned int sibling);
};
struct intel_context {
diff --git a/drivers/gpu/drm/i915/gt/intel_engine.h
b/drivers/gpu/drm/i915/gt/intel_engine.h
index f911c1224ab2..13bfb7ec33b2 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine.h
@@ -273,13 +273,41 @@ intel_engine_has_preempt_reset(const struct
intel_engine_cs *engine)
return intel_engine_has_preemption(engine);
}
+struct intel_context *
+intel_engine_create_virtual(struct intel_engine_cs **siblings,
+ unsigned int count);
looks like I missed this earlier, but this forward decl seems unneeded.
Not a forward decl, this is a header file which defines a function
implmented in gt/intel_engine_cs.c and used in gem/i915_gem_contexts.c.
It is absolutely needed.
D'oh! My mistake, my mind read this as a .c file because the functions
below are implemented in here. Now I get why it didn't bother me the
first time I reviewed this...
The r-b obviously stands.
Daniele
+
+static inline bool
+intel_virtual_engine_has_heartbeat(const struct intel_engine_cs *engine)
+{
+ /*
+* For non-GuC submission we expect the back-end to look at the
+* heartbeat status of the actual physical engine that the work
+* has been (or is being) scheduled on, so we should only reach
+* here with GuC submission enabled.
+*/
+ GEM_BUG_ON(!intel_engine_uses_guc(engine));
+
+ return intel_guc_virtual_engine_has_heartbeat(engine);
+}
+
static inline bool
intel_engine_has_heartbeat(const struct intel_engine_cs *engine)
{
if
Re: [Intel-gfx] [PATCH 04/10] drm/i915: move intel_context slab to direct module init/exit
On 26/07/2021 16:42, Jason Ekstrand wrote:
On Mon, Jul 26, 2021 at 10:30 AM Jason Ekstrand wrote:
On Mon, Jul 26, 2021 at 3:35 AM Tvrtko Ursulin
wrote:
On 23/07/2021 20:29, Daniel Vetter wrote:
With the global kmem_cache shrink infrastructure gone there's nothing
special and we can convert them over.
I'm doing this split up into each patch because there's quite a bit of
noise with removing the static global.slab_ce to just a
slab_ce.
Cc: Jason Ekstrand
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/gt/intel_context.c | 25 -
drivers/gpu/drm/i915/gt/intel_context.h | 3 +++
drivers/gpu/drm/i915/i915_globals.c | 2 --
drivers/gpu/drm/i915/i915_globals.h | 1 -
drivers/gpu/drm/i915/i915_pci.c | 2 ++
5 files changed, 13 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
b/drivers/gpu/drm/i915/gt/intel_context.c
index baa05fddd690..283382549a6f 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -7,7 +7,6 @@
#include "gem/i915_gem_pm.h"
#include "i915_drv.h"
-#include "i915_globals.h"
#include "i915_trace.h"
#include "intel_context.h"
@@ -15,14 +14,11 @@
#include "intel_engine_pm.h"
#include "intel_ring.h"
-static struct i915_global_context {
- struct i915_global base;
- struct kmem_cache *slab_ce;
-} global;
+struct kmem_cache *slab_ce;
Static? With that,
Reviewed-by: Jason Ekstrand
static struct intel_context *intel_context_alloc(void)
{
- return kmem_cache_zalloc(global.slab_ce, GFP_KERNEL);
+ return kmem_cache_zalloc(slab_ce, GFP_KERNEL);
}
static void rcu_context_free(struct rcu_head *rcu)
@@ -30,7 +26,7 @@ static void rcu_context_free(struct rcu_head *rcu)
struct intel_context *ce = container_of(rcu, typeof(*ce), rcu);
trace_intel_context_free(ce);
- kmem_cache_free(global.slab_ce, ce);
+ kmem_cache_free(slab_ce, ce);
}
void intel_context_free(struct intel_context *ce)
@@ -410,22 +406,17 @@ void intel_context_fini(struct intel_context *ce)
i915_active_fini(&ce->active);
}
-static void i915_global_context_exit(void)
+void i915_context_module_exit(void)
{
- kmem_cache_destroy(global.slab_ce);
+ kmem_cache_destroy(slab_ce);
}
-static struct i915_global_context global = { {
- .exit = i915_global_context_exit,
-} };
-
-int __init i915_global_context_init(void)
+int __init i915_context_module_init(void)
{
- global.slab_ce = KMEM_CACHE(intel_context, SLAB_HWCACHE_ALIGN);
- if (!global.slab_ce)
+ slab_ce = KMEM_CACHE(intel_context, SLAB_HWCACHE_ALIGN);
+ if (!slab_ce)
return -ENOMEM;
- i915_global_register(&global.base);
return 0;
}
diff --git a/drivers/gpu/drm/i915/gt/intel_context.h
b/drivers/gpu/drm/i915/gt/intel_context.h
index 974ef85320c2..a0ca82e3c40d 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.h
+++ b/drivers/gpu/drm/i915/gt/intel_context.h
@@ -30,6 +30,9 @@ void intel_context_init(struct intel_context *ce,
struct intel_engine_cs *engine);
void intel_context_fini(struct intel_context *ce);
+void i915_context_module_exit(void);
+int i915_context_module_init(void);
+
struct intel_context *
intel_context_create(struct intel_engine_cs *engine);
diff --git a/drivers/gpu/drm/i915/i915_globals.c
b/drivers/gpu/drm/i915/i915_globals.c
index 3de7cf22ec76..d36eb7dc40aa 100644
--- a/drivers/gpu/drm/i915/i915_globals.c
+++ b/drivers/gpu/drm/i915/i915_globals.c
@@ -7,7 +7,6 @@
#include
#include
-#include "gem/i915_gem_context.h"
#include "gem/i915_gem_object.h"
#include "i915_globals.h"
#include "i915_request.h"
@@ -32,7 +31,6 @@ static void __i915_globals_cleanup(void)
}
static __initconst int (* const initfn[])(void) = {
- i915_global_context_init,
i915_global_gem_context_init,
i915_global_objects_init,
i915_global_request_init,
diff --git a/drivers/gpu/drm/i915/i915_globals.h
b/drivers/gpu/drm/i915/i915_globals.h
index d80901ba75e3..60daa738a188 100644
--- a/drivers/gpu/drm/i915/i915_globals.h
+++ b/drivers/gpu/drm/i915/i915_globals.h
@@ -23,7 +23,6 @@ int i915_globals_init(void);
void i915_globals_exit(void);
/* constructors */
-int i915_global_context_init(void);
int i915_global_gem_context_init(void);
int i915_global_objects_init(void);
int i915_global_request_init(void);
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index f9527269e30a..266618157775 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -33,6 +33,7 @@
#include "i915_active.h"
#include "i915_buddy.h"
#include "i915_drv.h"
+#include "gem/i915_gem_context.h"
It's a bit ugly to go to a design where i915_pci.c has to include so
many random parts of i915. IMO for a complex driver like i915,
compartmentalizing so much knowledge about the intern
Re: [PATCH] drm/i915/userptr: Probe existence of backing struct pages upon creation
On 26/07/2021 16:14, Jason Ekstrand wrote:
On Mon, Jul 26, 2021 at 3:31 AM Maarten Lankhorst
wrote:
Op 23-07-2021 om 13:34 schreef Matthew Auld:
From: Chris Wilson
Jason Ekstrand requested a more efficient method than userptr+set-domain
to determine if the userptr object was backed by a complete set of pages
upon creation. To be more efficient than simply populating the userptr
using get_user_pages() (as done by the call to set-domain or execbuf),
we can walk the tree of vm_area_struct and check for gaps or vma not
backed by struct page (VM_PFNMAP). The question is how to handle
VM_MIXEDMAP which may be either struct page or pfn backed...
With discrete we are going to drop support for set_domain(), so offering
a way to probe the pages, without having to resort to dummy batches has
been requested.
v2:
- add new query param for the PROBE flag, so userspace can easily
check if the kernel supports it(Jason).
- use mmap_read_{lock, unlock}.
- add some kernel-doc.
v3:
- In the docs also mention that PROBE doesn't guarantee that the pages
will remain valid by the time they are actually used(Tvrtko).
- Add a small comment for the hole finding logic(Jason).
- Move the param next to all the other params which just return true.
Testcase: igt/gem_userptr_blits/probe
Signed-off-by: Chris Wilson
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Maarten Lankhorst
Cc: Tvrtko Ursulin
Cc: Jordan Justen
Cc: Kenneth Graunke
Cc: Jason Ekstrand
Cc: Daniel Vetter
Cc: Ramalingam C
Reviewed-by: Tvrtko Ursulin
Acked-by: Kenneth Graunke
Reviewed-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 41 -
drivers/gpu/drm/i915/i915_getparam.c| 1 +
include/uapi/drm/i915_drm.h | 20 ++
3 files changed, 61 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
b/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
index 56edfeff8c02..468a7a617fbf 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
@@ -422,6 +422,34 @@ static const struct drm_i915_gem_object_ops
i915_gem_userptr_ops = {
#endif
+static int
+probe_range(struct mm_struct *mm, unsigned long addr, unsigned long len)
+{
+ const unsigned long end = addr + len;
+ struct vm_area_struct *vma;
+ int ret = -EFAULT;
+
+ mmap_read_lock(mm);
+ for (vma = find_vma(mm, addr); vma; vma = vma->vm_next) {
+ /* Check for holes, note that we also update the addr below */
+ if (vma->vm_start > addr)
+ break;
+
+ if (vma->vm_flags & (VM_PFNMAP | VM_MIXEDMAP))
+ break;
+
+ if (vma->vm_end >= end) {
+ ret = 0;
+ break;
+ }
+
+ addr = vma->vm_end;
+ }
+ mmap_read_unlock(mm);
+
+ return ret;
+}
+
/*
* Creates a new mm object that wraps some normal memory from the process
* context - user memory.
@@ -477,7 +505,8 @@ i915_gem_userptr_ioctl(struct drm_device *dev,
}
if (args->flags & ~(I915_USERPTR_READ_ONLY |
- I915_USERPTR_UNSYNCHRONIZED))
+ I915_USERPTR_UNSYNCHRONIZED |
+ I915_USERPTR_PROBE))
return -EINVAL;
if (i915_gem_object_size_2big(args->user_size))
@@ -504,6 +533,16 @@ i915_gem_userptr_ioctl(struct drm_device *dev,
return -ENODEV;
}
+ if (args->flags & I915_USERPTR_PROBE) {
+ /*
+ * Check that the range pointed to represents real struct
+ * pages and not iomappings (at this moment in time!)
+ */
+ ret = probe_range(current->mm, args->user_ptr, args->user_size);
+ if (ret)
+ return ret;
+ }
+
#ifdef CONFIG_MMU_NOTIFIER
obj = i915_gem_object_alloc();
if (obj == NULL)
diff --git a/drivers/gpu/drm/i915/i915_getparam.c
b/drivers/gpu/drm/i915/i915_getparam.c
index 24e18219eb50..bbb7cac43eb4 100644
--- a/drivers/gpu/drm/i915/i915_getparam.c
+++ b/drivers/gpu/drm/i915/i915_getparam.c
@@ -134,6 +134,7 @@ int i915_getparam_ioctl(struct drm_device *dev, void *data,
case I915_PARAM_HAS_EXEC_FENCE_ARRAY:
case I915_PARAM_HAS_EXEC_SUBMIT_FENCE:
case I915_PARAM_HAS_EXEC_TIMELINE_FENCES:
+ case I915_PARAM_HAS_USERPTR_PROBE:
/* For the time being all of these are always true;
* if some supported hardware does not have one of these
* features this value needs to be provided from
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 975087553ea0..0d290535a6e5 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -674,6 +674,9 @@ typedef struct drm_i915_irq_wait {
*/
#define I915_PARAM_HAS_EXEC_TIMELINE_FENCES 55
+/* Query if the kernel supports the I915_US
