[Intel-gfx] [PATCH v2 1/6] drm: add writeback pointers to drm_connector
Changing drm_connector and drm_encoder feilds to pointers in
drm_writeback_connector as the elements of struct
drm_writeback_connector are:
struct drm_writeback_connector {
struct drm_connector base;
struct drm_encoder encoder;
Similarly the elements of intel_encoder and intel_connector
are:
struct intel_encoder {
struct drm_encoder base;
struct intel_connector {
struct drm_connector base;
The function drm_writeback_connector_init() will initialize the
drm_connector and drm_encoder and attach them as well.
Since the drm_connector/encoder are both struct in
drm_writeback_connector and intel_connector/encoder, we need
one of them to be a pointer so we can reference them or else we
will be pointing to 2 seprate instances.
Usually the struct defined in drm framework pointing to any
struct will be pointer and allocating them and initialization
will be done with the users.
Like struct drm_connector and drm_encoder are part of drm
framework and the users of these such as i915 have included them
in their struct intel_connector and intel_encoder. Likewise
struct drm_writeback_connector is a special connector and hence
is not a user of drm_connector and hence this should be pointers.
Adding drm_writeback_connector to drm_connector so that
writeback_connector can be fetched from drm_connector as the previous
container_of method won't work due to change in the feilds of
drm_connector and drm_encoder in drm_writeback_connector.
Note:The corresponding ripple effect due to the above changes namely in
two drivers as I can see it komeda and vkms have been dealt with in the
upcoming patches of this series.
Signed-off-by: Kandpal Suraj
---
drivers/gpu/drm/drm_writeback.c | 19 ++-
include/drm/drm_connector.h | 3 +++
include/drm/drm_writeback.h | 6 +++---
3 files changed, 16 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/drm_writeback.c b/drivers/gpu/drm/drm_writeback.c
index dccf4504f1bb..47238db42363 100644
--- a/drivers/gpu/drm/drm_writeback.c
+++ b/drivers/gpu/drm/drm_writeback.c
@@ -87,7 +87,7 @@ static const char *drm_writeback_fence_get_driver_name(struct
dma_fence *fence)
struct drm_writeback_connector *wb_connector =
fence_to_wb_connector(fence);
- return wb_connector->base.dev->driver->name;
+ return wb_connector->base->dev->driver->name;
}
static const char *
@@ -177,7 +177,7 @@ int drm_writeback_connector_init(struct drm_device *dev,
const u32 *formats, int n_formats)
{
struct drm_property_blob *blob;
- struct drm_connector *connector = &wb_connector->base;
+ struct drm_connector *connector = wb_connector->base;
struct drm_mode_config *config = &dev->mode_config;
int ret = create_writeback_properties(dev);
@@ -189,14 +189,15 @@ int drm_writeback_connector_init(struct drm_device *dev,
if (IS_ERR(blob))
return PTR_ERR(blob);
- drm_encoder_helper_add(&wb_connector->encoder, enc_helper_funcs);
- ret = drm_encoder_init(dev, &wb_connector->encoder,
+ drm_encoder_helper_add(wb_connector->encoder, enc_helper_funcs);
+ ret = drm_encoder_init(dev, wb_connector->encoder,
&drm_writeback_encoder_funcs,
DRM_MODE_ENCODER_VIRTUAL, NULL);
if (ret)
goto fail;
connector->interlace_allowed = 0;
+ connector->wb_connector = wb_connector;
ret = drm_connector_init(dev, connector, con_funcs,
DRM_MODE_CONNECTOR_WRITEBACK);
@@ -204,7 +205,7 @@ int drm_writeback_connector_init(struct drm_device *dev,
goto connector_fail;
ret = drm_connector_attach_encoder(connector,
- &wb_connector->encoder);
+ wb_connector->encoder);
if (ret)
goto attach_fail;
@@ -233,7 +234,7 @@ int drm_writeback_connector_init(struct drm_device *dev,
attach_fail:
drm_connector_cleanup(connector);
connector_fail:
- drm_encoder_cleanup(&wb_connector->encoder);
+ drm_encoder_cleanup(wb_connector->encoder);
fail:
drm_property_blob_put(blob);
return ret;
@@ -263,7 +264,7 @@ int drm_writeback_prepare_job(struct drm_writeback_job *job)
{
struct drm_writeback_connector *connector = job->connector;
const struct drm_connector_helper_funcs *funcs =
- connector->base.helper_private;
+ connector->base->helper_private;
int ret;
if (funcs->prepare_writeback_job) {
@@ -315,7 +316,7 @@ void drm_writeback_cleanup_job(struct drm_writeback_job
*job)
{
struct drm_writeback_connector *connector = job->connector;
const struct drm_connector_helper_funcs *funcs =
- connector->base.helper_private;
+ connector->base->helper_pri
[Intel-gfx] [PATCH v2 2/6] drm/arm/komeda : change driver to use drm_writeback_connector.base pointer
Making changes to komeda driver because we had to change
drm_writeback_connector.base into a pointer the reason for which is
expained in the Patch (drm: add writeback pointers to drm_connector).
Signed-off-by: Kandpal Suraj
---
drivers/gpu/drm/arm/display/komeda/komeda_crtc.c | 2 +-
drivers/gpu/drm/arm/display/komeda/komeda_kms.h | 3 ++-
.../gpu/drm/arm/display/komeda/komeda_wb_connector.c | 11 ++-
3 files changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
index 59172acb9738..eb37f41c1790 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
@@ -265,7 +265,7 @@ komeda_crtc_do_flush(struct drm_crtc *crtc,
if (slave && has_bit(slave->id, kcrtc_st->affected_pipes))
komeda_pipeline_update(slave, old->state);
- conn_st = wb_conn ? wb_conn->base.base.state : NULL;
+ conn_st = wb_conn ? wb_conn->base.base->state : NULL;
if (conn_st && conn_st->writeback_job)
drm_writeback_queue_job(&wb_conn->base, conn_st);
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_kms.h
b/drivers/gpu/drm/arm/display/komeda/komeda_kms.h
index 456f3c435719..8d83883a1d99 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_kms.h
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_kms.h
@@ -53,6 +53,7 @@ struct komeda_plane_state {
* struct komeda_wb_connector
*/
struct komeda_wb_connector {
+ struct drm_connector conn;
/** @base: &drm_writeback_connector */
struct drm_writeback_connector base;
@@ -136,7 +137,7 @@ struct komeda_kms_dev {
static inline bool is_writeback_only(struct drm_crtc_state *st)
{
struct komeda_wb_connector *wb_conn = to_kcrtc(st->crtc)->wb_conn;
- struct drm_connector *conn = wb_conn ? &wb_conn->base.base : NULL;
+ struct drm_connector *conn = wb_conn ? wb_conn->base.base : NULL;
return conn && (st->connector_mask == BIT(drm_connector_index(conn)));
}
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c
b/drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c
index e465cc4879c9..2c3dec59fd88 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c
@@ -51,7 +51,7 @@ komeda_wb_encoder_atomic_check(struct drm_encoder *encoder,
return -EINVAL;
}
- wb_layer = to_kconn(to_wb_conn(conn_st->connector))->wb_layer;
+ wb_layer =
to_kconn(drm_connector_to_writeback(conn_st->connector))->wb_layer;
/*
* No need for a full modested when the only connector changed is the
@@ -123,7 +123,7 @@ komeda_wb_connector_fill_modes(struct drm_connector
*connector,
static void komeda_wb_connector_destroy(struct drm_connector *connector)
{
drm_connector_cleanup(connector);
- kfree(to_kconn(to_wb_conn(connector)));
+ kfree(to_kconn(drm_connector_to_writeback(connector)));
}
static const struct drm_connector_funcs komeda_wb_connector_funcs = {
@@ -155,7 +155,8 @@ static int komeda_wb_connector_add(struct komeda_kms_dev
*kms,
kwb_conn->wb_layer = kcrtc->master->wb_layer;
wb_conn = &kwb_conn->base;
- wb_conn->encoder.possible_crtcs = BIT(drm_crtc_index(&kcrtc->base));
+ wb_conn->base = &kwb_conn->conn;
+ wb_conn->encoder->possible_crtcs = BIT(drm_crtc_index(&kcrtc->base));
formats = komeda_get_layer_fourcc_list(&mdev->fmt_tbl,
kwb_conn->wb_layer->layer_type,
@@ -171,9 +172,9 @@ static int komeda_wb_connector_add(struct komeda_kms_dev
*kms,
return err;
}
- drm_connector_helper_add(&wb_conn->base, &komeda_wb_conn_helper_funcs);
+ drm_connector_helper_add(wb_conn->base, &komeda_wb_conn_helper_funcs);
- info = &kwb_conn->base.base.display_info;
+ info = &kwb_conn->base.base->display_info;
info->bpc = __fls(kcrtc->master->improc->supported_color_depths);
info->color_formats = kcrtc->master->improc->supported_color_formats;
--
2.17.1
[Intel-gfx] [PATCH v2 3/6] drm/vkms: change vkms driver to use drm_writeback_connector.base pointer
Changing vkms driver to accomadate the change of
drm_writeback_connector.base to a pointer the reason for which is
explained in the Patch(drm: add writeback pointers to drm_connector).
Signed-off-by: Kandpal Suraj
---
drivers/gpu/drm/vkms/vkms_writeback.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/vkms/vkms_writeback.c
b/drivers/gpu/drm/vkms/vkms_writeback.c
index 8694227f555f..374431471f49 100644
--- a/drivers/gpu/drm/vkms/vkms_writeback.c
+++ b/drivers/gpu/drm/vkms/vkms_writeback.c
@@ -114,7 +114,7 @@ static void vkms_wb_atomic_commit(struct drm_connector
*conn,
struct vkms_device *vkmsdev = drm_device_to_vkms_device(conn->dev);
struct vkms_output *output = &vkmsdev->output;
struct drm_writeback_connector *wb_conn = &output->wb_connector;
- struct drm_connector_state *conn_state = wb_conn->base.state;
+ struct drm_connector_state *conn_state = wb_conn->base->state;
struct vkms_crtc_state *crtc_state = output->composer_state;
if (!conn_state)
@@ -139,9 +139,12 @@ static const struct drm_connector_helper_funcs
vkms_wb_conn_helper_funcs = {
int vkms_enable_writeback_connector(struct vkms_device *vkmsdev)
{
struct drm_writeback_connector *wb = &vkmsdev->output.wb_connector;
+ struct vkms_output *output = &vkmsdev->output;
- vkmsdev->output.wb_connector.encoder.possible_crtcs = 1;
- drm_connector_helper_add(&wb->base, &vkms_wb_conn_helper_funcs);
+ wb->base = &output->connector;
+ wb->encoder = &output->encoder;
+ output->wb_connector.encoder->possible_crtcs = 1;
+ drm_connector_helper_add(wb->base, &vkms_wb_conn_helper_funcs);
return drm_writeback_connector_init(&vkmsdev->drm, wb,
&vkms_wb_connector_funcs,
--
2.17.1
[Intel-gfx] [PATCH v2 4/6] drm/vc4: vc4 driver changes to accommodate changes done in drm_writeback_connector structure
Changing vc4 driver to accomadate the change of
drm_writeback_connector.base and drm_writeback_connector.encoder
to a pointer the reason for which is explained in the
Patch(drm: add writeback pointers to drm_connector).
Signed-off-by: Kandpal Suraj
---
drivers/gpu/drm/vc4/vc4_txp.c | 20 ++--
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_txp.c b/drivers/gpu/drm/vc4/vc4_txp.c
index 9809ca3e2945..9882569d147c 100644
--- a/drivers/gpu/drm/vc4/vc4_txp.c
+++ b/drivers/gpu/drm/vc4/vc4_txp.c
@@ -151,6 +151,10 @@ struct vc4_txp {
struct platform_device *pdev;
+ struct drm_connector drm_conn;
+
+ struct drm_encoder drm_enc;
+
struct drm_writeback_connector connector;
void __iomem *regs;
@@ -159,12 +163,12 @@ struct vc4_txp {
static inline struct vc4_txp *encoder_to_vc4_txp(struct drm_encoder *encoder)
{
- return container_of(encoder, struct vc4_txp, connector.encoder);
+ return container_of(encoder, struct vc4_txp, drm_enc);
}
static inline struct vc4_txp *connector_to_vc4_txp(struct drm_connector *conn)
{
- return container_of(conn, struct vc4_txp, connector.base);
+ return container_of(conn, struct vc4_txp, drm_conn);
}
static const struct debugfs_reg32 txp_regs[] = {
@@ -467,6 +471,7 @@ static int vc4_txp_bind(struct device *dev, struct device
*master, void *data)
struct vc4_txp *txp;
struct drm_crtc *crtc;
struct drm_encoder *encoder;
+ struct drm_writeback_connector *wb_conn;
int ret, irq;
irq = platform_get_irq(pdev, 0);
@@ -491,10 +496,13 @@ static int vc4_txp_bind(struct device *dev, struct device
*master, void *data)
txp->regset.base = txp->regs;
txp->regset.regs = txp_regs;
txp->regset.nregs = ARRAY_SIZE(txp_regs);
+ wb_conn = &txp->connector;
+ wb_conn->base = &txp->drm_conn;
+ wb_conn->encoder = &txp->drm_enc;
- drm_connector_helper_add(&txp->connector.base,
+ drm_connector_helper_add(wb_conn->base,
&vc4_txp_connector_helper_funcs);
- ret = drm_writeback_connector_init(drm, &txp->connector,
+ ret = drm_writeback_connector_init(drm, wb_conn,
&vc4_txp_connector_funcs,
&vc4_txp_encoder_helper_funcs,
drm_fmts, ARRAY_SIZE(drm_fmts));
@@ -506,7 +514,7 @@ static int vc4_txp_bind(struct device *dev, struct device
*master, void *data)
if (ret)
return ret;
- encoder = &txp->connector.encoder;
+ encoder = txp->connector.encoder;
encoder->possible_crtcs = drm_crtc_mask(crtc);
ret = devm_request_irq(dev, irq, vc4_txp_interrupt, 0,
@@ -529,7 +537,7 @@ static void vc4_txp_unbind(struct device *dev, struct
device *master,
struct vc4_dev *vc4 = to_vc4_dev(drm);
struct vc4_txp *txp = dev_get_drvdata(dev);
- vc4_txp_connector_destroy(&txp->connector.base);
+ vc4_txp_connector_destroy(txp->connector.base);
vc4->txp = NULL;
}
--
2.17.1
[Intel-gfx] [PATCH v2 5/6] drm/rcar_du: changes to rcar-du driver resulting from drm_writeback_connector structure changes
Changing rcar_du driver to accomadate the change of
drm_writeback_connector.base and drm_writeback_connector.encoder
to a pointer the reason for which is explained in the
Patch(drm: add writeback pointers to drm_connector).
Signed-off-by: Kandpal Suraj
---
drivers/gpu/drm/rcar-du/rcar_du_crtc.h | 2 ++
drivers/gpu/drm/rcar-du/rcar_du_writeback.c | 8 +---
2 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
index 66e8839db708..68f387a04502 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
@@ -72,6 +72,8 @@ struct rcar_du_crtc {
const char *const *sources;
unsigned int sources_count;
+ struct drm_connector connector;
+ struct drm_encoder encoder;
struct drm_writeback_connector writeback;
};
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_writeback.c
b/drivers/gpu/drm/rcar-du/rcar_du_writeback.c
index c79d1259e49b..5b1e83380c47 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_writeback.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_writeback.c
@@ -200,8 +200,10 @@ int rcar_du_writeback_init(struct rcar_du_device *rcdu,
{
struct drm_writeback_connector *wb_conn = &rcrtc->writeback;
- wb_conn->encoder.possible_crtcs = 1 << drm_crtc_index(&rcrtc->crtc);
- drm_connector_helper_add(&wb_conn->base,
+ wb_conn->base = &rcrtc->connector;
+ wb_conn->encoder = &rcrtc->encoder;
+ wb_conn->encoder->possible_crtcs = 1 << drm_crtc_index(&rcrtc->crtc);
+ drm_connector_helper_add(wb_conn->base,
&rcar_du_wb_conn_helper_funcs);
return drm_writeback_connector_init(&rcdu->ddev, wb_conn,
@@ -220,7 +222,7 @@ void rcar_du_writeback_setup(struct rcar_du_crtc *rcrtc,
struct drm_framebuffer *fb;
unsigned int i;
- state = rcrtc->writeback.base.state;
+ state = rcrtc->writeback.base->state;
if (!state || !state->writeback_job)
return;
--
2.17.1
[Intel-gfx] [PATCH v2 6/6] drm/arm: changes to malidp driver resulting from drm_writeback_connector structure changes
Changing malidp driver to accomadate the change of
drm_writeback_connector.base and drm_writeback_connector.encoder
to a pointer the reason for which is explained in the
Patch(drm: add writeback pointers to drm_connector).
Signed-off-by: Kandpal Suraj
---
drivers/gpu/drm/arm/malidp_crtc.c | 2 +-
drivers/gpu/drm/arm/malidp_drv.h | 2 ++
drivers/gpu/drm/arm/malidp_mw.c | 12
3 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/arm/malidp_crtc.c
b/drivers/gpu/drm/arm/malidp_crtc.c
index 494075ddbef6..294aacd4beef 100644
--- a/drivers/gpu/drm/arm/malidp_crtc.c
+++ b/drivers/gpu/drm/arm/malidp_crtc.c
@@ -424,7 +424,7 @@ static int malidp_crtc_atomic_check(struct drm_crtc *crtc,
u32 new_mask = crtc_state->connector_mask;
if ((old_mask ^ new_mask) ==
- (1 << drm_connector_index(&malidp->mw_connector.base)))
+ (1 << drm_connector_index(malidp->mw_connector.base)))
crtc_state->connectors_changed = false;
}
diff --git a/drivers/gpu/drm/arm/malidp_drv.h b/drivers/gpu/drm/arm/malidp_drv.h
index cdfddfabf2d1..971810a685f1 100644
--- a/drivers/gpu/drm/arm/malidp_drv.h
+++ b/drivers/gpu/drm/arm/malidp_drv.h
@@ -31,6 +31,8 @@ struct malidp_error_stats {
struct malidp_drm {
struct malidp_hw_device *dev;
struct drm_crtc crtc;
+ struct drm_connector connector;
+ struct drm_encoder encoder;
struct drm_writeback_connector mw_connector;
wait_queue_head_t wq;
struct drm_pending_vblank_event *event;
diff --git a/drivers/gpu/drm/arm/malidp_mw.c b/drivers/gpu/drm/arm/malidp_mw.c
index f5847a79dd7e..9bd2e400cd3d 100644
--- a/drivers/gpu/drm/arm/malidp_mw.c
+++ b/drivers/gpu/drm/arm/malidp_mw.c
@@ -206,21 +206,25 @@ static u32 *get_writeback_formats(struct malidp_drm
*malidp, int *n_formats)
int malidp_mw_connector_init(struct drm_device *drm)
{
struct malidp_drm *malidp = drm->dev_private;
+ struct drm_writeback_connector *wb_conn;
u32 *formats;
int ret, n_formats;
if (!malidp->dev->hw->enable_memwrite)
return 0;
- malidp->mw_connector.encoder.possible_crtcs = 1 <<
drm_crtc_index(&malidp->crtc);
- drm_connector_helper_add(&malidp->mw_connector.base,
+ wb_conn = &malidp->mw_connector;
+ wb_conn->base = &malidp->connector;
+ wb_conn->encoder = &malidp->encoder;
+ malidp->mw_connector.encoder->possible_crtcs = 1 <<
drm_crtc_index(&malidp->crtc);
+ drm_connector_helper_add(wb_conn->base,
&malidp_mw_connector_helper_funcs);
formats = get_writeback_formats(malidp, &n_formats);
if (!formats)
return -ENOMEM;
- ret = drm_writeback_connector_init(drm, &malidp->mw_connector,
+ ret = drm_writeback_connector_init(drm, wb_conn,
&malidp_mw_connector_funcs,
&malidp_mw_encoder_helper_funcs,
formats, n_formats);
@@ -236,7 +240,7 @@ void malidp_mw_atomic_commit(struct drm_device *drm,
{
struct malidp_drm *malidp = drm->dev_private;
struct drm_writeback_connector *mw_conn = &malidp->mw_connector;
- struct drm_connector_state *conn_state = mw_conn->base.state;
+ struct drm_connector_state *conn_state = mw_conn->base->state;
struct malidp_hw_device *hwdev = malidp->dev;
struct malidp_mw_connector_state *mw_state;
--
2.17.1
[Intel-gfx] [PATCH 0/6] drm writeback connector changes
This patch series contains drm_writeback_connector structure change i.e change of drm_connector and drm_encoder fields to a pointer the reason for which is explained in patch(1/6) drm: add writeback pointers to drm_connector and the accompanying changes to the different drivers that were effected by it. I had perviously floated a patch series but missed some of the drivers that were effected by the change hence refloating the patch series Kandpal Suraj (6): drm: add writeback pointers to drm_connector drm/arm/komeda : change driver to use drm_writeback_connector.base pointer drm/vkms: change vkms driver to use drm_writeback_connector.base pointer drm/vc4: vc4 driver changes to accommodate changes done in drm_writeback_connector structure drm/rcar_du: changes to rcar-du driver resulting from drm_writeback_connector structure changes drm/arm: changes to malidp driver resulting from drm_writeback_connector structure changes .../gpu/drm/arm/display/komeda/komeda_crtc.c | 2 +- .../gpu/drm/arm/display/komeda/komeda_kms.h | 3 ++- .../arm/display/komeda/komeda_wb_connector.c | 11 +- drivers/gpu/drm/arm/malidp_crtc.c | 2 +- drivers/gpu/drm/arm/malidp_drv.h | 2 ++ drivers/gpu/drm/arm/malidp_mw.c | 12 +++ drivers/gpu/drm/drm_writeback.c | 19 +- drivers/gpu/drm/rcar-du/rcar_du_crtc.h| 2 ++ drivers/gpu/drm/rcar-du/rcar_du_writeback.c | 8 +--- drivers/gpu/drm/vc4/vc4_txp.c | 20 +-- drivers/gpu/drm/vkms/vkms_writeback.c | 9 ++--- include/drm/drm_connector.h | 3 +++ include/drm/drm_writeback.h | 6 +++--- 13 files changed, 63 insertions(+), 36 deletions(-) -- 2.17.1
[Intel-gfx] [PATCH 1/6] drm: add writeback pointers to drm_connector
Changing drm_connector and drm_encoder feilds to pointers in
drm_writeback_connector as the elements of struct
drm_writeback_connector are:
struct drm_writeback_connector {
struct drm_connector base;
struct drm_encoder encoder;
Similarly the elements of intel_encoder and intel_connector
are:
struct intel_encoder {
struct drm_encoder base;
struct intel_connector {
struct drm_connector base;
The function drm_writeback_connector_init() will initialize the
drm_connector and drm_encoder and attach them as well.
Since the drm_connector/encoder are both struct in
drm_writeback_connector and intel_connector/encoder, we need
one of them to be a pointer so we can reference them or else we
will be pointing to 2 seprate instances.
Usually the struct defined in drm framework pointing to any
struct will be pointer and allocating them and initialization
will be done with the users.
Like struct drm_connector and drm_encoder are part of drm
framework and the users of these such as i915 have included them
in their struct intel_connector and intel_encoder. Likewise
struct drm_writeback_connector is a special connector and hence
is not a user of drm_connector and hence this should be pointers.
Adding drm_writeback_connector to drm_connector so that
writeback_connector can be fetched from drm_connector as the previous
container_of method won't work due to change in the feilds of
drm_connector and drm_encoder in drm_writeback_connector.
Note:The corresponding ripple effect due to the above changes namely in
two drivers as I can see it komeda and vkms have been dealt with in the
upcoming patches of this series.
Signed-off-by: Kandpal Suraj
Reviewed-by: Abhinav Kumar
---
drivers/gpu/drm/drm_writeback.c | 19 ++-
include/drm/drm_connector.h | 3 +++
include/drm/drm_writeback.h | 6 +++---
3 files changed, 16 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/drm_writeback.c b/drivers/gpu/drm/drm_writeback.c
index dccf4504f1bb..47238db42363 100644
--- a/drivers/gpu/drm/drm_writeback.c
+++ b/drivers/gpu/drm/drm_writeback.c
@@ -87,7 +87,7 @@ static const char *drm_writeback_fence_get_driver_name(struct
dma_fence *fence)
struct drm_writeback_connector *wb_connector =
fence_to_wb_connector(fence);
- return wb_connector->base.dev->driver->name;
+ return wb_connector->base->dev->driver->name;
}
static const char *
@@ -177,7 +177,7 @@ int drm_writeback_connector_init(struct drm_device *dev,
const u32 *formats, int n_formats)
{
struct drm_property_blob *blob;
- struct drm_connector *connector = &wb_connector->base;
+ struct drm_connector *connector = wb_connector->base;
struct drm_mode_config *config = &dev->mode_config;
int ret = create_writeback_properties(dev);
@@ -189,14 +189,15 @@ int drm_writeback_connector_init(struct drm_device *dev,
if (IS_ERR(blob))
return PTR_ERR(blob);
- drm_encoder_helper_add(&wb_connector->encoder, enc_helper_funcs);
- ret = drm_encoder_init(dev, &wb_connector->encoder,
+ drm_encoder_helper_add(wb_connector->encoder, enc_helper_funcs);
+ ret = drm_encoder_init(dev, wb_connector->encoder,
&drm_writeback_encoder_funcs,
DRM_MODE_ENCODER_VIRTUAL, NULL);
if (ret)
goto fail;
connector->interlace_allowed = 0;
+ connector->wb_connector = wb_connector;
ret = drm_connector_init(dev, connector, con_funcs,
DRM_MODE_CONNECTOR_WRITEBACK);
@@ -204,7 +205,7 @@ int drm_writeback_connector_init(struct drm_device *dev,
goto connector_fail;
ret = drm_connector_attach_encoder(connector,
- &wb_connector->encoder);
+ wb_connector->encoder);
if (ret)
goto attach_fail;
@@ -233,7 +234,7 @@ int drm_writeback_connector_init(struct drm_device *dev,
attach_fail:
drm_connector_cleanup(connector);
connector_fail:
- drm_encoder_cleanup(&wb_connector->encoder);
+ drm_encoder_cleanup(wb_connector->encoder);
fail:
drm_property_blob_put(blob);
return ret;
@@ -263,7 +264,7 @@ int drm_writeback_prepare_job(struct drm_writeback_job *job)
{
struct drm_writeback_connector *connector = job->connector;
const struct drm_connector_helper_funcs *funcs =
- connector->base.helper_private;
+ connector->base->helper_private;
int ret;
if (funcs->prepare_writeback_job) {
@@ -315,7 +316,7 @@ void drm_writeback_cleanup_job(struct drm_writeback_job
*job)
{
struct drm_writeback_connector *connector = job->connector;
const struct drm_connector_helper_funcs *funcs =
- connector->base.helper_private;
+
[Intel-gfx] [PATCH 2/6] drm/arm/komeda : change driver to use drm_writeback_connector.base pointer
Making changes to komeda driver because we had to change
drm_writeback_connector.base into a pointer the reason for which is
expained in the Patch (drm: add writeback pointers to drm_connector).
Signed-off-by: Kandpal Suraj
Reviewed-by: Carsten Haitzler
---
drivers/gpu/drm/arm/display/komeda/komeda_crtc.c | 2 +-
drivers/gpu/drm/arm/display/komeda/komeda_kms.h | 3 ++-
.../gpu/drm/arm/display/komeda/komeda_wb_connector.c | 11 ++-
3 files changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
index 59172acb9738..eb37f41c1790 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
@@ -265,7 +265,7 @@ komeda_crtc_do_flush(struct drm_crtc *crtc,
if (slave && has_bit(slave->id, kcrtc_st->affected_pipes))
komeda_pipeline_update(slave, old->state);
- conn_st = wb_conn ? wb_conn->base.base.state : NULL;
+ conn_st = wb_conn ? wb_conn->base.base->state : NULL;
if (conn_st && conn_st->writeback_job)
drm_writeback_queue_job(&wb_conn->base, conn_st);
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_kms.h
b/drivers/gpu/drm/arm/display/komeda/komeda_kms.h
index 456f3c435719..8d83883a1d99 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_kms.h
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_kms.h
@@ -53,6 +53,7 @@ struct komeda_plane_state {
* struct komeda_wb_connector
*/
struct komeda_wb_connector {
+ struct drm_connector conn;
/** @base: &drm_writeback_connector */
struct drm_writeback_connector base;
@@ -136,7 +137,7 @@ struct komeda_kms_dev {
static inline bool is_writeback_only(struct drm_crtc_state *st)
{
struct komeda_wb_connector *wb_conn = to_kcrtc(st->crtc)->wb_conn;
- struct drm_connector *conn = wb_conn ? &wb_conn->base.base : NULL;
+ struct drm_connector *conn = wb_conn ? wb_conn->base.base : NULL;
return conn && (st->connector_mask == BIT(drm_connector_index(conn)));
}
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c
b/drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c
index e465cc4879c9..2c3dec59fd88 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c
@@ -51,7 +51,7 @@ komeda_wb_encoder_atomic_check(struct drm_encoder *encoder,
return -EINVAL;
}
- wb_layer = to_kconn(to_wb_conn(conn_st->connector))->wb_layer;
+ wb_layer =
to_kconn(drm_connector_to_writeback(conn_st->connector))->wb_layer;
/*
* No need for a full modested when the only connector changed is the
@@ -123,7 +123,7 @@ komeda_wb_connector_fill_modes(struct drm_connector
*connector,
static void komeda_wb_connector_destroy(struct drm_connector *connector)
{
drm_connector_cleanup(connector);
- kfree(to_kconn(to_wb_conn(connector)));
+ kfree(to_kconn(drm_connector_to_writeback(connector)));
}
static const struct drm_connector_funcs komeda_wb_connector_funcs = {
@@ -155,7 +155,8 @@ static int komeda_wb_connector_add(struct komeda_kms_dev
*kms,
kwb_conn->wb_layer = kcrtc->master->wb_layer;
wb_conn = &kwb_conn->base;
- wb_conn->encoder.possible_crtcs = BIT(drm_crtc_index(&kcrtc->base));
+ wb_conn->base = &kwb_conn->conn;
+ wb_conn->encoder->possible_crtcs = BIT(drm_crtc_index(&kcrtc->base));
formats = komeda_get_layer_fourcc_list(&mdev->fmt_tbl,
kwb_conn->wb_layer->layer_type,
@@ -171,9 +172,9 @@ static int komeda_wb_connector_add(struct komeda_kms_dev
*kms,
return err;
}
- drm_connector_helper_add(&wb_conn->base, &komeda_wb_conn_helper_funcs);
+ drm_connector_helper_add(wb_conn->base, &komeda_wb_conn_helper_funcs);
- info = &kwb_conn->base.base.display_info;
+ info = &kwb_conn->base.base->display_info;
info->bpc = __fls(kcrtc->master->improc->supported_color_depths);
info->color_formats = kcrtc->master->improc->supported_color_formats;
--
2.17.1
[Intel-gfx] [PATCH 3/6] drm/vkms: change vkms driver to use drm_writeback_connector.base pointer
Changing vkms driver to accomadate the change of
drm_writeback_connector.base to a pointer the reason for which is
explained in the Patch(drm: add writeback pointers to drm_connector).
Signed-off-by: Kandpal Suraj
---
drivers/gpu/drm/vkms/vkms_writeback.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/vkms/vkms_writeback.c
b/drivers/gpu/drm/vkms/vkms_writeback.c
index 8694227f555f..374431471f49 100644
--- a/drivers/gpu/drm/vkms/vkms_writeback.c
+++ b/drivers/gpu/drm/vkms/vkms_writeback.c
@@ -114,7 +114,7 @@ static void vkms_wb_atomic_commit(struct drm_connector
*conn,
struct vkms_device *vkmsdev = drm_device_to_vkms_device(conn->dev);
struct vkms_output *output = &vkmsdev->output;
struct drm_writeback_connector *wb_conn = &output->wb_connector;
- struct drm_connector_state *conn_state = wb_conn->base.state;
+ struct drm_connector_state *conn_state = wb_conn->base->state;
struct vkms_crtc_state *crtc_state = output->composer_state;
if (!conn_state)
@@ -139,9 +139,12 @@ static const struct drm_connector_helper_funcs
vkms_wb_conn_helper_funcs = {
int vkms_enable_writeback_connector(struct vkms_device *vkmsdev)
{
struct drm_writeback_connector *wb = &vkmsdev->output.wb_connector;
+ struct vkms_output *output = &vkmsdev->output;
- vkmsdev->output.wb_connector.encoder.possible_crtcs = 1;
- drm_connector_helper_add(&wb->base, &vkms_wb_conn_helper_funcs);
+ wb->base = &output->connector;
+ wb->encoder = &output->encoder;
+ output->wb_connector.encoder->possible_crtcs = 1;
+ drm_connector_helper_add(wb->base, &vkms_wb_conn_helper_funcs);
return drm_writeback_connector_init(&vkmsdev->drm, wb,
&vkms_wb_connector_funcs,
--
2.17.1
[Intel-gfx] [PATCH 4/6] drm/vc4: vc4 driver changes to accommodate changes done in drm_writeback_connector structure
Changing vc4 driver to accomadate the change of
drm_writeback_connector.base and drm_writeback_connector.encoder
to a pointer the reason for which is explained in the
Patch(drm: add writeback pointers to drm_connector).
Signed-off-by: Kandpal Suraj
---
drivers/gpu/drm/vc4/vc4_txp.c | 20 ++--
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_txp.c b/drivers/gpu/drm/vc4/vc4_txp.c
index 9809ca3e2945..9882569d147c 100644
--- a/drivers/gpu/drm/vc4/vc4_txp.c
+++ b/drivers/gpu/drm/vc4/vc4_txp.c
@@ -151,6 +151,10 @@ struct vc4_txp {
struct platform_device *pdev;
+ struct drm_connector drm_conn;
+
+ struct drm_encoder drm_enc;
+
struct drm_writeback_connector connector;
void __iomem *regs;
@@ -159,12 +163,12 @@ struct vc4_txp {
static inline struct vc4_txp *encoder_to_vc4_txp(struct drm_encoder *encoder)
{
- return container_of(encoder, struct vc4_txp, connector.encoder);
+ return container_of(encoder, struct vc4_txp, drm_enc);
}
static inline struct vc4_txp *connector_to_vc4_txp(struct drm_connector *conn)
{
- return container_of(conn, struct vc4_txp, connector.base);
+ return container_of(conn, struct vc4_txp, drm_conn);
}
static const struct debugfs_reg32 txp_regs[] = {
@@ -467,6 +471,7 @@ static int vc4_txp_bind(struct device *dev, struct device
*master, void *data)
struct vc4_txp *txp;
struct drm_crtc *crtc;
struct drm_encoder *encoder;
+ struct drm_writeback_connector *wb_conn;
int ret, irq;
irq = platform_get_irq(pdev, 0);
@@ -491,10 +496,13 @@ static int vc4_txp_bind(struct device *dev, struct device
*master, void *data)
txp->regset.base = txp->regs;
txp->regset.regs = txp_regs;
txp->regset.nregs = ARRAY_SIZE(txp_regs);
+ wb_conn = &txp->connector;
+ wb_conn->base = &txp->drm_conn;
+ wb_conn->encoder = &txp->drm_enc;
- drm_connector_helper_add(&txp->connector.base,
+ drm_connector_helper_add(wb_conn->base,
&vc4_txp_connector_helper_funcs);
- ret = drm_writeback_connector_init(drm, &txp->connector,
+ ret = drm_writeback_connector_init(drm, wb_conn,
&vc4_txp_connector_funcs,
&vc4_txp_encoder_helper_funcs,
drm_fmts, ARRAY_SIZE(drm_fmts));
@@ -506,7 +514,7 @@ static int vc4_txp_bind(struct device *dev, struct device
*master, void *data)
if (ret)
return ret;
- encoder = &txp->connector.encoder;
+ encoder = txp->connector.encoder;
encoder->possible_crtcs = drm_crtc_mask(crtc);
ret = devm_request_irq(dev, irq, vc4_txp_interrupt, 0,
@@ -529,7 +537,7 @@ static void vc4_txp_unbind(struct device *dev, struct
device *master,
struct vc4_dev *vc4 = to_vc4_dev(drm);
struct vc4_txp *txp = dev_get_drvdata(dev);
- vc4_txp_connector_destroy(&txp->connector.base);
+ vc4_txp_connector_destroy(txp->connector.base);
vc4->txp = NULL;
}
--
2.17.1
[Intel-gfx] [PATCH 5/6] drm/rcar_du: changes to rcar-du driver resulting from drm_writeback_connector structure changes
Changing rcar_du driver to accomadate the change of
drm_writeback_connector.base and drm_writeback_connector.encoder
to a pointer the reason for which is explained in the
Patch(drm: add writeback pointers to drm_connector).
Signed-off-by: Kandpal Suraj
---
drivers/gpu/drm/rcar-du/rcar_du_crtc.h | 2 ++
drivers/gpu/drm/rcar-du/rcar_du_writeback.c | 8 +---
2 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
index 66e8839db708..68f387a04502 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
@@ -72,6 +72,8 @@ struct rcar_du_crtc {
const char *const *sources;
unsigned int sources_count;
+ struct drm_connector connector;
+ struct drm_encoder encoder;
struct drm_writeback_connector writeback;
};
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_writeback.c
b/drivers/gpu/drm/rcar-du/rcar_du_writeback.c
index c79d1259e49b..5b1e83380c47 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_writeback.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_writeback.c
@@ -200,8 +200,10 @@ int rcar_du_writeback_init(struct rcar_du_device *rcdu,
{
struct drm_writeback_connector *wb_conn = &rcrtc->writeback;
- wb_conn->encoder.possible_crtcs = 1 << drm_crtc_index(&rcrtc->crtc);
- drm_connector_helper_add(&wb_conn->base,
+ wb_conn->base = &rcrtc->connector;
+ wb_conn->encoder = &rcrtc->encoder;
+ wb_conn->encoder->possible_crtcs = 1 << drm_crtc_index(&rcrtc->crtc);
+ drm_connector_helper_add(wb_conn->base,
&rcar_du_wb_conn_helper_funcs);
return drm_writeback_connector_init(&rcdu->ddev, wb_conn,
@@ -220,7 +222,7 @@ void rcar_du_writeback_setup(struct rcar_du_crtc *rcrtc,
struct drm_framebuffer *fb;
unsigned int i;
- state = rcrtc->writeback.base.state;
+ state = rcrtc->writeback.base->state;
if (!state || !state->writeback_job)
return;
--
2.17.1
[Intel-gfx] [PATCH 6/6] drm/arm: changes to malidp driver resulting from drm_writeback_connector structure changes
Changing malidp driver to accomadate the change of
drm_writeback_connector.base and drm_writeback_connector.encoder
to a pointer the reason for which is explained in the
Patch(drm: add writeback pointers to drm_connector).
Signed-off-by: Kandpal Suraj
---
drivers/gpu/drm/arm/malidp_crtc.c | 2 +-
drivers/gpu/drm/arm/malidp_drv.h | 2 ++
drivers/gpu/drm/arm/malidp_mw.c | 12
3 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/arm/malidp_crtc.c
b/drivers/gpu/drm/arm/malidp_crtc.c
index 494075ddbef6..294aacd4beef 100644
--- a/drivers/gpu/drm/arm/malidp_crtc.c
+++ b/drivers/gpu/drm/arm/malidp_crtc.c
@@ -424,7 +424,7 @@ static int malidp_crtc_atomic_check(struct drm_crtc *crtc,
u32 new_mask = crtc_state->connector_mask;
if ((old_mask ^ new_mask) ==
- (1 << drm_connector_index(&malidp->mw_connector.base)))
+ (1 << drm_connector_index(malidp->mw_connector.base)))
crtc_state->connectors_changed = false;
}
diff --git a/drivers/gpu/drm/arm/malidp_drv.h b/drivers/gpu/drm/arm/malidp_drv.h
index cdfddfabf2d1..971810a685f1 100644
--- a/drivers/gpu/drm/arm/malidp_drv.h
+++ b/drivers/gpu/drm/arm/malidp_drv.h
@@ -31,6 +31,8 @@ struct malidp_error_stats {
struct malidp_drm {
struct malidp_hw_device *dev;
struct drm_crtc crtc;
+ struct drm_connector connector;
+ struct drm_encoder encoder;
struct drm_writeback_connector mw_connector;
wait_queue_head_t wq;
struct drm_pending_vblank_event *event;
diff --git a/drivers/gpu/drm/arm/malidp_mw.c b/drivers/gpu/drm/arm/malidp_mw.c
index f5847a79dd7e..9bd2e400cd3d 100644
--- a/drivers/gpu/drm/arm/malidp_mw.c
+++ b/drivers/gpu/drm/arm/malidp_mw.c
@@ -206,21 +206,25 @@ static u32 *get_writeback_formats(struct malidp_drm
*malidp, int *n_formats)
int malidp_mw_connector_init(struct drm_device *drm)
{
struct malidp_drm *malidp = drm->dev_private;
+ struct drm_writeback_connector *wb_conn;
u32 *formats;
int ret, n_formats;
if (!malidp->dev->hw->enable_memwrite)
return 0;
- malidp->mw_connector.encoder.possible_crtcs = 1 <<
drm_crtc_index(&malidp->crtc);
- drm_connector_helper_add(&malidp->mw_connector.base,
+ wb_conn = &malidp->mw_connector;
+ wb_conn->base = &malidp->connector;
+ wb_conn->encoder = &malidp->encoder;
+ malidp->mw_connector.encoder->possible_crtcs = 1 <<
drm_crtc_index(&malidp->crtc);
+ drm_connector_helper_add(wb_conn->base,
&malidp_mw_connector_helper_funcs);
formats = get_writeback_formats(malidp, &n_formats);
if (!formats)
return -ENOMEM;
- ret = drm_writeback_connector_init(drm, &malidp->mw_connector,
+ ret = drm_writeback_connector_init(drm, wb_conn,
&malidp_mw_connector_funcs,
&malidp_mw_encoder_helper_funcs,
formats, n_formats);
@@ -236,7 +240,7 @@ void malidp_mw_atomic_commit(struct drm_device *drm,
{
struct malidp_drm *malidp = drm->dev_private;
struct drm_writeback_connector *mw_conn = &malidp->mw_connector;
- struct drm_connector_state *conn_state = mw_conn->base.state;
+ struct drm_connector_state *conn_state = mw_conn->base->state;
struct malidp_hw_device *hwdev = malidp->dev;
struct malidp_mw_connector_state *mw_state;
--
2.17.1
[Intel-gfx] [PATCH v2] dma-buf-map: Rename to iosys-map
Rename struct dma_buf_map to struct iosys_map and corresponding APIs. Over time dma-buf-map grew up to more functionality than the one used by dma-buf: in fact it's just a shim layer to abstract system memory, that can be accessed via regular load and store, from IO memory, that needs to be accessed via arch helpers. The idea is to extend this API so it can fulfill other needs, internal to a single driver. Example: in the i915 driver it's desired to share the implementation for integrated graphics, which uses mostly system memory, with discrete graphics, which may need to access IO memory. The conversion was mostly done with the following semantic patch: @r1@ @@ - struct dma_buf_map + struct iosys_map @r2@ @@ ( - DMA_BUF_MAP_INIT_VADDR + IOSYS_MAP_INIT_VADDR | - dma_buf_map_set_vaddr + iosys_map_set_vaddr | - dma_buf_map_set_vaddr_iomem + iosys_map_set_vaddr_iomem | - dma_buf_map_is_equal + iosys_map_is_equal | - dma_buf_map_is_null + iosys_map_is_null | - dma_buf_map_is_set + iosys_map_is_set | - dma_buf_map_clear + iosys_map_clear | - dma_buf_map_memcpy_to + iosys_map_memcpy_to | - dma_buf_map_incr + iosys_map_incr ) @@ @@ - #include + #include Then some files had their includes adjusted and some comments were update to remove mentions to dma-buf-map. Signed-off-by: Lucas De Marchi --- Documentation/driver-api/dma-buf.rst | 4 +- Documentation/gpu/todo.rst| 20 +- MAINTAINERS | 8 +- drivers/dma-buf/dma-buf.c | 22 +- drivers/dma-buf/heaps/cma_heap.c | 10 +- drivers/dma-buf/heaps/system_heap.c | 10 +- drivers/gpu/drm/ast/ast_drv.h | 2 +- drivers/gpu/drm/ast/ast_mode.c| 8 +- drivers/gpu/drm/drm_cache.c | 18 +- drivers/gpu/drm/drm_client.c | 9 +- drivers/gpu/drm/drm_fb_helper.c | 12 +- drivers/gpu/drm/drm_gem.c | 12 +- drivers/gpu/drm/drm_gem_cma_helper.c | 9 +- drivers/gpu/drm/drm_gem_framebuffer_helper.c | 16 +- drivers/gpu/drm/drm_gem_shmem_helper.c| 15 +- drivers/gpu/drm/drm_gem_ttm_helper.c | 4 +- drivers/gpu/drm/drm_gem_vram_helper.c | 25 +- drivers/gpu/drm/drm_internal.h| 6 +- drivers/gpu/drm/drm_mipi_dbi.c| 8 +- drivers/gpu/drm/drm_prime.c | 4 +- drivers/gpu/drm/etnaviv/etnaviv_drv.h | 2 +- drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c | 8 +- drivers/gpu/drm/gud/gud_pipe.c| 4 +- drivers/gpu/drm/hyperv/hyperv_drm_modeset.c | 5 +- drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c| 8 +- .../drm/i915/gem/selftests/i915_gem_dmabuf.c | 6 +- .../gpu/drm/i915/gem/selftests/mock_dmabuf.c | 6 +- drivers/gpu/drm/lima/lima_gem.c | 3 +- drivers/gpu/drm/lima/lima_sched.c | 4 +- drivers/gpu/drm/mediatek/mtk_drm_gem.c| 7 +- drivers/gpu/drm/mediatek/mtk_drm_gem.h| 5 +- drivers/gpu/drm/mgag200/mgag200_mode.c| 4 +- drivers/gpu/drm/msm/msm_drv.h | 4 +- drivers/gpu/drm/msm/msm_gem_prime.c | 6 +- drivers/gpu/drm/panfrost/panfrost_perfcnt.c | 13 +- drivers/gpu/drm/qxl/qxl_display.c | 8 +- drivers/gpu/drm/qxl/qxl_draw.c| 6 +- drivers/gpu/drm/qxl/qxl_drv.h | 10 +- drivers/gpu/drm/qxl/qxl_object.c | 8 +- drivers/gpu/drm/qxl/qxl_object.h | 4 +- drivers/gpu/drm/qxl/qxl_prime.c | 4 +- drivers/gpu/drm/radeon/radeon_gem.c | 1 + drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 9 +- drivers/gpu/drm/rockchip/rockchip_drm_gem.h | 5 +- drivers/gpu/drm/tegra/gem.c | 10 +- drivers/gpu/drm/tiny/cirrus.c | 8 +- drivers/gpu/drm/tiny/gm12u320.c | 7 +- drivers/gpu/drm/ttm/ttm_bo_util.c | 16 +- drivers/gpu/drm/ttm/ttm_resource.c| 26 +- drivers/gpu/drm/ttm/ttm_tt.c | 6 +- drivers/gpu/drm/udl/udl_modeset.c | 3 +- drivers/gpu/drm/vboxvideo/vbox_mode.c | 4 +- drivers/gpu/drm/vkms/vkms_composer.c | 4 +- drivers/gpu/drm/vkms/vkms_drv.h | 6 +- drivers/gpu/drm/vkms/vkms_plane.c | 2 +- drivers/gpu/drm/vkms/vkms_writeback.c | 2 +- drivers/gpu/drm/xen/xen_drm_front_gem.c | 7 +- drivers/gpu/drm/xen/xen_drm_front_gem.h | 6 +- .../common/videobuf2/videobuf2-dma-contig.c | 8 +- .../media/common/videobuf2/videobuf2-dma-sg.c | 9 +- .../common/video
Re: [Intel-gfx] [PATCH 3/4] drm/i915/vga: switch to use VGA definitions from video/vga.h
On Wed, 12 Jan 2022, Ville Syrjälä wrote: > On Tue, Jan 11, 2022 at 10:55:44AM +0200, Jani Nikula wrote: >> On Mon, 10 Jan 2022, Ville Syrjälä wrote: >> > On Mon, Jan 10, 2022 at 11:57:39AM +0200, Jani Nikula wrote: >> >> The video/vga.h has macros for the VGA registers. Switch to use them. >> >> >> >> Suggested-by: Matt Roper >> >> Signed-off-by: Jani Nikula >> >> --- >> >> drivers/gpu/drm/i915/display/intel_vga.c | 9 + >> >> 1 file changed, 5 insertions(+), 4 deletions(-) >> >> >> >> diff --git a/drivers/gpu/drm/i915/display/intel_vga.c >> >> b/drivers/gpu/drm/i915/display/intel_vga.c >> >> index fa779f7ea415..43c12036c1fa 100644 >> >> --- a/drivers/gpu/drm/i915/display/intel_vga.c >> >> +++ b/drivers/gpu/drm/i915/display/intel_vga.c >> >> @@ -7,6 +7,7 @@ >> >> #include >> >> >> >> #include >> >> +#include >> >> >> >> #include "i915_drv.h" >> >> #include "intel_de.h" >> >> @@ -34,9 +35,9 @@ void intel_vga_disable(struct drm_i915_private >> >> *dev_priv) >> >> >> >> /* WaEnableVGAAccessThroughIOPort:ctg,elk,ilk,snb,ivb,vlv,hsw */ >> >> vga_get_uninterruptible(pdev, VGA_RSRC_LEGACY_IO); >> >> - outb(SR01, VGA_SR_INDEX); >> >> - sr1 = inb(VGA_SR_DATA); >> >> - outb(sr1 | 1 << 5, VGA_SR_DATA); >> >> + outb(VGA_SEQ_CLOCK_MODE, VGA_SEQ_I); >> > >> > Not a huge fan of some of these defines since now I have >> > no idea what register this is selecting. >> >> It's a bit silly that we have our own macros for this stuff, but I get >> the point. Took me a while to figure the changes out because the macros >> in video/vga.h aren't even grouped in a helpful way. >> >> I guess you'd prefer patch [1] over patches 3-4 in this series then? For >> me the main goal is to just reduce the size of i915_reg.h. > > I guess another option is to go with this and just > s/VGA_SEQ_CLOCK_MODE/0x01/ or something. I think the rest > of the defines are probably clear enough. I dropped the ball here a bit. If I respin the same patches, but with the above line changed to one of these, is it okay? Which do you prefer? 1) outb(VGA_SEQ_CLOCK_MODE, VGA_SEQ_I); /* SR01 */ 2) #define SR01 VGA_SEQ_CLOCK_MODE outb(SR01, VGA_SEQ_I); 3) outb(0x01, VGA_SEQ_I); BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH v2] dma-buf-map: Rename to iosys-map
On Wed, Feb 02, 2022 at 10:25:28AM +0100, Christian König wrote: Am 02.02.22 um 10:11 schrieb Lucas De Marchi: [SNIP] diff --git a/MAINTAINERS b/MAINTAINERS index d03ad8da1f36..112676f11792 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -5675,7 +5675,6 @@ T:git git://anongit.freedesktop.org/drm/drm-misc F: Documentation/driver-api/dma-buf.rst F: drivers/dma-buf/ F: include/linux/*fence.h Oh, that is not correct to begin with. right, include/linux/dma-fence* -F: include/linux/dma-buf* That here should probably be changed to point directly to include/linux/dma-buf.h, but that can come later on. thanks for catching that. I will change it on next version and add your (and any additional) ack. Lucas De Marchi Feel free to add an Acked-by: Christian König to the patch. If nobody objects I'm going to push it drm-misc-next and provide a follow up to cleanup the MAINTAINERS file a bit more. Regards, Christian. F: include/linux/dma-resv.h K: \bdma_(?:buf|fence|resv)\b @@ -9976,6 +9975,13 @@ F: include/linux/iova.h F: include/linux/of_iommu.h F: include/uapi/linux/iommu.h +IOSYS-MAP HELPERS +M: Thomas Zimmermann +L: dri-de...@lists.freedesktop.org +S: Maintained +T: git git://anongit.freedesktop.org/drm/drm-misc +F: include/linux/iosys-map.h +
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm writeback connector changes
== Series Details == Series: drm writeback connector changes URL : https://patchwork.freedesktop.org/series/99610/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
Re: [Intel-gfx] [PATCH 5/8] drm/i915/dp: rewrite DP 2.0 128b/132b link training based on errata
On Wed, 26 Jan 2022, Ville Syrjälä wrote:
> On Tue, Jan 25, 2022 at 07:03:43PM +0200, Jani Nikula wrote:
>> The DP 2.0 errata completely overhauls the 128b/132b link training, with
>> no provisions for backward compatibility with the original DP 2.0
>> specification.
>>
>> The changes are too intrusive to consider reusing the same code for both
>> 8b/10b and 128b/132b, mainly because the LTTPR channel equalisation is
>> done concurrently instead of serialized.
>>
>> NOTES:
>>
>> * It's a bit unclear when to wait for DP_INTERLANE_ALIGN_DONE and
>> per-lane DP_LANE_SYMBOL_LOCKED. Figure xx4 in the SCR implies the
>> LANEx_CHANNEL_EQ_DONE sequence may end with either 0x77,0x77,0x85 *or*
>> 0x33,0x33,0x84 (for four lane configuration in DPCD 0x202..0x204)
>> i.e. without the above bits set. Text elsewhere seems contradictory or
>> incomplete.
>>
>> * We read entire link status (6 bytes) everywhere instead of individual
>> DPCD addresses.
>>
>> * There are some subtle ambiguities or contradictions in the order of
>> some DPCD access and TPS signal enables/disables. It's also not clear
>> whether these are significant.
>>
>> Cc: Uma Shankar
>> Cc: Ville Syrjälä
>> Signed-off-by: Jani Nikula
>> ---
>> .../drm/i915/display/intel_dp_link_training.c | 252 +-
>> 1 file changed, 251 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
>> b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
>> index 4e507aa75a03..8bb6a296f421 100644
>> --- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
>> +++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
>> @@ -1102,6 +1102,250 @@ intel_dp_link_train_all_phys(struct intel_dp
>> *intel_dp,
>> return ret;
>> }
>>
>> +
>> +/*
>> + * 128b/132b DP LANEx_EQ_DONE Sequence (DP 2.0 E11 3.5.2.16.1)
>> + */
>> +static bool
>> +intel_dp_128b132b_lane_eq(struct intel_dp *intel_dp,
>> + const struct intel_crtc_state *crtc_state)
>> +{
>> +struct intel_encoder *encoder = &dp_to_dig_port(intel_dp)->base;
>> +struct drm_i915_private *i915 = to_i915(encoder->base.dev);
>> +u8 link_status[DP_LINK_STATUS_SIZE];
>> +int delay_us;
>> +int try, max_tries = 20;
>> +unsigned long deadline;
>> +
>> +/*
>> + * Reset signal levels. Start transmitting 128b/132b TPS1.
>> + *
>> + * Put DPRX and LTTPRs (if any) into intra-hop AUX mode by writing TPS1
>> + * in DP_TRAINING_PATTERN_SET.
>> + */
>> +if (!intel_dp_reset_link_train(intel_dp, crtc_state, DP_PHY_DPRX,
>> + DP_TRAINING_PATTERN_1)) {
>> +drm_err(&i915->drm,
>> +"[ENCODER:%d:%s] Failed to start 128b/132b TPS1\n",
>> +encoder->base.base.id, encoder->base.name);
>> +return false;
>> +}
>> +
>> +delay_us = drm_dp_128b132b_read_aux_rd_interval(&intel_dp->aux);
>> +
>> +/* Read the initial TX FFE settings. */
>> +if (drm_dp_dpcd_read_link_status(&intel_dp->aux, link_status) < 0) {
>> +drm_err(&i915->drm,
>> +"[ENCODER:%d:%s] Failed to read TX FFE presets\n",
>> +encoder->base.base.id, encoder->base.name);
>> +return false;
>> +}
>> +
>> +/* Update signal levels and training set as requested. */
>> +intel_dp_get_adjust_train(intel_dp, crtc_state, DP_PHY_DPRX,
>> link_status);
>> +if (!intel_dp_update_link_train(intel_dp, crtc_state, DP_PHY_DPRX)) {
>> +drm_err(&i915->drm,
>> +"[ENCODER:%d:%s] Failed to set initial TX FFE
>> settings\n",
>> +encoder->base.base.id, encoder->base.name);
>> +return false;
>> +}
>> +
>> +/* Start transmitting 128b/132b TPS2. */
>> +if (!intel_dp_set_link_train(intel_dp, crtc_state, DP_PHY_DPRX,
>> + DP_TRAINING_PATTERN_2)) {
>> +drm_err(&i915->drm,
>> +"[ENCODER:%d:%s] Failed to start 128b/132b TPS2\n",
>> +encoder->base.base.id, encoder->base.name);
>> +return false;
>> +}
>> +
>> +for (try = 0; try < max_tries; try++) {
>> +usleep_range(delay_us, 2 * delay_us);
>> +
>> +/*
>> + * The delay may get updated. The transmitter shall read the
>> + * delay before link status during link training.
>> + */
>> +delay_us = drm_dp_128b132b_read_aux_rd_interval(&intel_dp->aux);
>> +
>> +if (drm_dp_dpcd_read_link_status(&intel_dp->aux, link_status) <
>> 0) {
>> +drm_err(&i915->drm,
>> +"[ENCODER:%d:%s] Failed to read link status\n",
>> +encoder->base.base.id, encoder->base.name);
>> +return false;
>> +}
>> +
>> +if (drm_dp_128b132b_link_training_failed(link_status)) {
>> +
Re: [Intel-gfx] [PATCH 3/4] drm/i915/vga: switch to use VGA definitions from video/vga.h
On Wed, Feb 02, 2022 at 11:17:11AM +0200, Jani Nikula wrote: > On Wed, 12 Jan 2022, Ville Syrjälä wrote: > > On Tue, Jan 11, 2022 at 10:55:44AM +0200, Jani Nikula wrote: > >> On Mon, 10 Jan 2022, Ville Syrjälä wrote: > >> > On Mon, Jan 10, 2022 at 11:57:39AM +0200, Jani Nikula wrote: > >> >> The video/vga.h has macros for the VGA registers. Switch to use them. > >> >> > >> >> Suggested-by: Matt Roper > >> >> Signed-off-by: Jani Nikula > >> >> --- > >> >> drivers/gpu/drm/i915/display/intel_vga.c | 9 + > >> >> 1 file changed, 5 insertions(+), 4 deletions(-) > >> >> > >> >> diff --git a/drivers/gpu/drm/i915/display/intel_vga.c > >> >> b/drivers/gpu/drm/i915/display/intel_vga.c > >> >> index fa779f7ea415..43c12036c1fa 100644 > >> >> --- a/drivers/gpu/drm/i915/display/intel_vga.c > >> >> +++ b/drivers/gpu/drm/i915/display/intel_vga.c > >> >> @@ -7,6 +7,7 @@ > >> >> #include > >> >> > >> >> #include > >> >> +#include > >> >> > >> >> #include "i915_drv.h" > >> >> #include "intel_de.h" > >> >> @@ -34,9 +35,9 @@ void intel_vga_disable(struct drm_i915_private > >> >> *dev_priv) > >> >> > >> >> /* WaEnableVGAAccessThroughIOPort:ctg,elk,ilk,snb,ivb,vlv,hsw */ > >> >> vga_get_uninterruptible(pdev, VGA_RSRC_LEGACY_IO); > >> >> - outb(SR01, VGA_SR_INDEX); > >> >> - sr1 = inb(VGA_SR_DATA); > >> >> - outb(sr1 | 1 << 5, VGA_SR_DATA); > >> >> + outb(VGA_SEQ_CLOCK_MODE, VGA_SEQ_I); > >> > > >> > Not a huge fan of some of these defines since now I have > >> > no idea what register this is selecting. > >> > >> It's a bit silly that we have our own macros for this stuff, but I get > >> the point. Took me a while to figure the changes out because the macros > >> in video/vga.h aren't even grouped in a helpful way. > >> > >> I guess you'd prefer patch [1] over patches 3-4 in this series then? For > >> me the main goal is to just reduce the size of i915_reg.h. > > > > I guess another option is to go with this and just > > s/VGA_SEQ_CLOCK_MODE/0x01/ or something. I think the rest > > of the defines are probably clear enough. > > I dropped the ball here a bit. If I respin the same patches, but with > the above line changed to one of these, is it okay? Which do you prefer? > > 1)outb(VGA_SEQ_CLOCK_MODE, VGA_SEQ_I); /* SR01 */ > > 2)#define SR01 VGA_SEQ_CLOCK_MODE > outb(SR01, VGA_SEQ_I); > > 3)outb(0x01, VGA_SEQ_I); 3 seems like the best option of these. -- Ville Syrjälä Intel
Re: [Intel-gfx] [PATCH 5/8] drm/i915/dp: rewrite DP 2.0 128b/132b link training based on errata
On Thu, 27 Jan 2022, Ville Syrjälä wrote:
> On Tue, Jan 25, 2022 at 07:03:43PM +0200, Jani Nikula wrote:
>
>> +static bool
>> +intel_dp_128b132b_lane_cds(struct intel_dp *intel_dp,
>> + const struct intel_crtc_state *crtc_state,
>> + int lttpr_count)
>> +{
>> +struct intel_encoder *encoder = &dp_to_dig_port(intel_dp)->base;
>> +struct drm_i915_private *i915 = to_i915(encoder->base.dev);
>> +u8 link_status[DP_LINK_STATUS_SIZE];
>> +unsigned long deadline;
>> +
>> +if (drm_dp_dpcd_writeb(&intel_dp->aux, DP_TRAINING_PATTERN_SET,
>> + DP_TRAINING_PATTERN_2_CDS) != 1) {
>> +drm_err(&i915->drm,
>> +"[ENCODER:%d:%s] Failed to start 128b/132b TPS2 CDS\n",
>> +encoder->base.base.id, encoder->base.name);
>> +return false;
>> +}
>> +
>> +deadline = jiffies + msecs_to_jiffies((lttpr_count + 1) * 20);
>> +for (;;) {
>> +usleep_range(2000, 3000);
>> +
>> +if (drm_dp_dpcd_read_link_status(&intel_dp->aux, link_status) <
>> 0) {
>> +drm_err(&i915->drm,
>> +"[ENCODER:%d:%s] Failed to read link status\n",
>> +encoder->base.base.id, encoder->base.name);
>> +return false;
>> +}
>> +
>> +if (drm_dp_128b132b_cds_interlane_align_done(link_status) &&
>> +drm_dp_128b132b_lane_symbol_locked(link_status,
>> crtc_state->lane_count)) {
>
> I'm thinkin we want to check for both eq done and symbol locked here,
> just like we do with 8b10b.
I guess so, although I don't think the spec explicitly calls that out.
Fixed anyway.
>
>> +drm_dbg_kms(&i915->drm,
>> +"[ENCODER:%d:%s] CDS interlane align
>> done\n",
>> +encoder->base.base.id, encoder->base.name);
>> +break;
>> +}
>> +
>> +if (drm_dp_128b132b_link_training_failed(link_status)) {
>> +intel_dp_dump_link_status(intel_dp, DP_PHY_DPRX,
>> link_status);
>> +drm_err(&i915->drm,
>> +"[ENCODER:%d:%s] Downstream link training
>> failure\n",
>> +encoder->base.base.id, encoder->base.name);
>> +return false;
>> +}
>> +
>> +if (time_after(jiffies, deadline)) {
>> +intel_dp_dump_link_status(intel_dp, DP_PHY_DPRX,
>> link_status);
>> +drm_err(&i915->drm,
>> +"[ENCODER:%d:%s] CDS timeout\n",
>> +encoder->base.base.id, encoder->base.name);
>> +return false;
>> +}
>> +}
>> +
>> +/* FIXME: Should DP_TRAINING_PATTERN_DISABLE be written first? */
>> +if (intel_dp->set_idle_link_train)
>> +intel_dp->set_idle_link_train(intel_dp, crtc_state);
>> +
>> +return true;
>> +}
--
Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH 10/20] drm/i915/selftests: mock test io_size
On 1/26/22 16:21, Matthew Auld wrote:
Check that mappable vs non-mappable matches our expectations.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Reviewed-by: Thomas Hellström
---
.../drm/i915/selftests/intel_memory_region.c | 143 ++
1 file changed, 143 insertions(+)
diff --git a/drivers/gpu/drm/i915/selftests/intel_memory_region.c
b/drivers/gpu/drm/i915/selftests/intel_memory_region.c
index 247f65f02bbf..04ae29779206 100644
--- a/drivers/gpu/drm/i915/selftests/intel_memory_region.c
+++ b/drivers/gpu/drm/i915/selftests/intel_memory_region.c
@@ -17,6 +17,7 @@
#include "gem/i915_gem_context.h"
#include "gem/i915_gem_lmem.h"
#include "gem/i915_gem_region.h"
+#include "gem/i915_gem_ttm.h"
#include "gem/selftests/igt_gem_utils.h"
#include "gem/selftests/mock_context.h"
#include "gt/intel_engine_pm.h"
@@ -512,6 +513,147 @@ static int igt_mock_max_segment(void *arg)
return err;
}
+static u64 igt_object_mappable_total(struct drm_i915_gem_object *obj)
+{
+ struct intel_memory_region *mr = obj->mm.region;
+ struct i915_ttm_buddy_resource *bman_res =
+ to_ttm_buddy_resource(obj->mm.res);
+ struct drm_buddy *mm = bman_res->mm;
+ struct drm_buddy_block *block;
+ u64 total;
+
+ total = 0;
+ list_for_each_entry(block, &bman_res->blocks, link) {
+ u64 start = drm_buddy_block_offset(block);
+ u64 end = start + drm_buddy_block_size(mm, block);
+
+ if (start < mr->io_size)
+ total += min_t(u64, end, mr->io_size) - start;
+ }
+
+ return total;
+}
+
+static int igt_mock_io_size(void *arg)
+{
+ struct intel_memory_region *mr = arg;
+ struct drm_i915_private *i915 = mr->i915;
+ struct drm_i915_gem_object *obj;
+ u64 mappable_theft_total;
+ u64 io_size;
+ u64 total;
+ u64 ps;
+ u64 rem;
+ u64 size;
+ I915_RND_STATE(prng);
+ LIST_HEAD(objects);
+ int err = 0;
+
+ ps = SZ_4K;
+ if (i915_prandom_u64_state(&prng) & 1)
+ ps = SZ_64K; /* For something like DG2 */
+
+ div64_u64_rem(i915_prandom_u64_state(&prng), SZ_8G, &total);
+ total = round_down(total, ps);
+ total = max_t(u64, total, SZ_1G);
+
+ div64_u64_rem(i915_prandom_u64_state(&prng), total - ps, &io_size);
+ io_size = round_down(io_size, ps);
+ io_size = max_t(u64, io_size, SZ_256M); /* 256M seems to be the common
lower limit */
+
+ pr_info("%s with ps=%llx, io_size=%llx, total=%llx\n",
+ __func__, ps, io_size, total);
+
+ mr = mock_region_create(i915, 0, total, ps, 0, io_size);
+ if (IS_ERR(mr)) {
+ err = PTR_ERR(mr);
+ goto out_err;
+ }
+
+ mappable_theft_total = 0;
+ rem = total - io_size;
+ do {
+ div64_u64_rem(i915_prandom_u64_state(&prng), rem, &size);
+ size = round_down(size, ps);
+ size = max(size, ps);
+
+ obj = igt_object_create(mr, &objects, size,
+ I915_BO_ALLOC_TOPDOWN);
+ if (IS_ERR(obj)) {
+ pr_err("%s TOPDOWN failed with rem=%llx, size=%llx\n",
+ __func__, rem, size);
+ err = PTR_ERR(obj);
+ goto out_close;
+ }
+
+ mappable_theft_total += igt_object_mappable_total(obj);
+ rem -= size;
+ } while (rem);
+
+ pr_info("%s mappable theft=(%lluMiB/%lluMiB), total=%lluMiB\n",
+ __func__,
+ (u64)mappable_theft_total >> 20,
+ (u64)io_size >> 20,
+ (u64)total >> 20);
+
+ /*
+* Even if we allocate all of the non-mappable portion, we should still
+* be able to dip into the mappable portion.
+*/
+ obj = igt_object_create(mr, &objects, io_size,
+ I915_BO_ALLOC_TOPDOWN);
+ if (IS_ERR(obj)) {
+ pr_err("%s allocation unexpectedly failed\n", __func__);
+ err = PTR_ERR(obj);
+ goto out_close;
+ }
+
+ close_objects(mr, &objects);
+
+ rem = io_size;
+ do {
+ div64_u64_rem(i915_prandom_u64_state(&prng), rem, &size);
+ size = round_down(size, ps);
+ size = max(size, ps);
+
+ obj = igt_object_create(mr, &objects, size, 0);
+ if (IS_ERR(obj)) {
+ pr_err("%s MAPPABLE failed with rem=%llx, size=%llx\n",
+ __func__, rem, size);
+ err = PTR_ERR(obj);
+ goto out_close;
+ }
+
+ if (igt_object_mappable_total(obj) != size) {
+ pr_err("%s allocation is not mappable(size=%llx)\n",
+ __func__, size);
+
Re: [Intel-gfx] [RFC 0/2] Compile out integrated
On 01/02/2022 17:28, Lucas De Marchi wrote: On Tue, Feb 01, 2022 at 07:09:14PM +0200, Jani Nikula wrote: On Tue, 01 Feb 2022, Lucas De Marchi wrote: On Tue, Feb 01, 2022 at 11:15:31AM +, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Quicky and dirty hack based on some old ideas. Thought maybe the approach might interest the Arm port guys. But with IS_GEN_RANGE removed easy gains are not so big so meh.. Maybe some more easy wins with IS_DISPLAY_VER but I haven't looked into that side. 3884664 449681 6720 4341065 423d49 i915.ko.tip 3599989 429034 6688 4035711 3d947f i915.ko.noigp By these numbers probably it's hard to justify. Another thing to consider is that it's very common to have on the same system both integrated and discrete - doing this would remove at compile time any chance of driving the integrated one. I guess the point was, the arm systems won't have integrated, and it's anyway going to be a separate build. so probably the focus and argument here should not be about size reduction. From patch 1 I see: +config DRM_I915_INTEGRATED_GPU_SUPPORT + bool "Support integrated GPUs" + default y + depends on DRM_I915 + help + Include support for integrated GPUs. If it's something that depends on arch rather than providing an option in menuconfig, then I think it could be some interesting investigation. However, I can't see how it would help with removing some code paths in the driver (e.g. the clflush() calls we were talking about in another patch series) since the code elimination would all happen at link time. Clflush class of problems is yet another orthogonal set of problems. Yes, idea was that the Kconfig option would be selected by Arm, or deselected by x86, whatever. But there is also a case for letting it be user visible. In general, I thought at least, we should look into not building/deploying binary code for irrelevant hardware on Arm builds. If that is clear and agreeable then I think the approach how to get there is really multi-pronged. 1) What you are partly doing with "clflush" type series. Make Arm relevant code paths actually compile on Arm. 2a) What I sent in this series - it's simple/easy dead code elimination from a single compilation unit. 2b) *If* we resurrected GRAPHICS_VER check where "ver" is part of the macro, eg. not doing "if (GRAPHICS_VER <=> N)" but "if (GRAPHICS_VERN)", or "if IS_GRAPHICS_VER(N, FOREVER)", then the same approach would be more effective. Because if N or range is the macro parameter, we can make it dead code based on Kconfig. This is what I demonstrated few years ago by being able to compile out ~3rd of a driver when selecting only execlists platforms, AFAIR. And which is why I was a bit unhappy this was getting removed not so long ago. 3) Complex step is putting LTO into use to allow dead code elimination between compilation units. Think: file1.c: RUNTIME_INFO->needs_blah = IS_PLATFORM && blah file2.c if (RUNTIME_INFO->needs_blah) ..dead code eliminated by LTO only.. Few years ago Andi Kleen had a proof of concept of KBuild LTO but I don't know what is the status of that. If LTO can be enabled then work from steps 2a&b automatically works much much better. 4) If LTO is not there yet maybe see how to slightly refactor the code so that we can completely drop compilation units from the Makefile. Drop files like gt/intel_ring_submission.c, or similar if we have or can create candidates. Regards, Tvrtko
[Intel-gfx] ✓ Fi.CI.BAT: success for drm writeback connector changes
== Series Details == Series: drm writeback connector changes URL : https://patchwork.freedesktop.org/series/99610/ State : success == Summary == CI Bug Log - changes from CI_DRM_11177 -> Patchwork_22152 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22152/index.html Participating hosts (45 -> 43) -- Additional (1): fi-pnv-d510 Missing(3): fi-bsw-cyan fi-icl-u2 fi-bdw-samus Known issues Here are the changes found in Patchwork_22152 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_cs_nop@sync-fork-compute0: - fi-snb-2600:NOTRUN -> [SKIP][1] ([fdo#109271]) +17 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22152/fi-snb-2600/igt@amdgpu/amd_cs_...@sync-fork-compute0.html * igt@gem_exec_suspend@basic-s3@smem: - fi-bdw-5557u: [PASS][2] -> [INCOMPLETE][3] ([i915#146]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11177/fi-bdw-5557u/igt@gem_exec_suspend@basic...@smem.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22152/fi-bdw-5557u/igt@gem_exec_suspend@basic...@smem.html * igt@kms_psr@primary_page_flip: - fi-skl-6600u: [PASS][4] -> [FAIL][5] ([i915#4547]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11177/fi-skl-6600u/igt@kms_psr@primary_page_flip.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22152/fi-skl-6600u/igt@kms_psr@primary_page_flip.html * igt@prime_vgem@basic-userptr: - fi-pnv-d510:NOTRUN -> [SKIP][6] ([fdo#109271]) +57 similar issues [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22152/fi-pnv-d510/igt@prime_v...@basic-userptr.html * igt@runner@aborted: - fi-skl-6600u: NOTRUN -> [FAIL][7] ([i915#4312]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22152/fi-skl-6600u/igt@run...@aborted.html Possible fixes * igt@i915_selftest@live@hangcheck: - fi-snb-2600:[INCOMPLETE][8] ([i915#3921]) -> [PASS][9] [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11177/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22152/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html * igt@kms_frontbuffer_tracking@basic: - fi-cfl-8109u: [DMESG-FAIL][10] ([i915#295]) -> [PASS][11] [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11177/fi-cfl-8109u/igt@kms_frontbuffer_track...@basic.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22152/fi-cfl-8109u/igt@kms_frontbuffer_track...@basic.html * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-b: - fi-cfl-8109u: [DMESG-WARN][12] ([i915#295]) -> [PASS][13] +10 similar issues [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11177/fi-cfl-8109u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-b.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22152/fi-cfl-8109u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-b.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [i915#146]: https://gitlab.freedesktop.org/drm/intel/issues/146 [i915#295]: https://gitlab.freedesktop.org/drm/intel/issues/295 [i915#3921]: https://gitlab.freedesktop.org/drm/intel/issues/3921 [i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312 [i915#4547]: https://gitlab.freedesktop.org/drm/intel/issues/4547 Build changes - * Linux: CI_DRM_11177 -> Patchwork_22152 CI-20190529: 20190529 CI_DRM_11177: 22db355d36b6c879c506e293b0255bf951df1dff @ git://anongit.freedesktop.org/gfx-ci/linux IGT_6337: 7c9c034619ef9dbfbfe041fbf3973a1cf1ac7a22 @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_22152: 1a9c28f7f63392f2af9f676132e80cf0ad5df75b @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 1a9c28f7f633 drm/arm: changes to malidp driver resulting from drm_writeback_connector structure changes 3e0f8d61446a drm/rcar_du: changes to rcar-du driver resulting from drm_writeback_connector structure changes 735e7a771cba drm/vc4: vc4 driver changes to accommodate changes done in drm_writeback_connector structure 4a3bcb073fe2 drm/vkms: change vkms driver to use drm_writeback_connector.base pointer 57ef80524dde drm/arm/komeda : change driver to use drm_writeback_connector.base pointer bb318d5a51f7 drm: add writeback pointers to drm_connector == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22152/index.html
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for dma-buf-map: Rename to iosys-map
== Series Details == Series: dma-buf-map: Rename to iosys-map URL : https://patchwork.freedesktop.org/series/99612/ State : warning == Summary == $ dim checkpatch origin/drm-tip b6a44abcc53f dma-buf-map: Rename to iosys-map -:194: WARNING:AVOID_BUG: Avoid crashing the kernel - try using WARN_ON & recovery code rather than BUG() or BUG_ON() #194: FILE: drivers/dma-buf/dma-buf.c:1279: + BUG_ON(iosys_map_is_null(&dmabuf->vmap_ptr)); -:200: WARNING:AVOID_BUG: Avoid crashing the kernel - try using WARN_ON & recovery code rather than BUG() or BUG_ON() #200: FILE: drivers/dma-buf/dma-buf.c:1284: + BUG_ON(iosys_map_is_set(&dmabuf->vmap_ptr)); -:215: WARNING:AVOID_BUG: Avoid crashing the kernel - try using WARN_ON & recovery code rather than BUG() or BUG_ON() #215: FILE: drivers/dma-buf/dma-buf.c:1311: + BUG_ON(iosys_map_is_null(&dmabuf->vmap_ptr)); -:218: WARNING:AVOID_BUG: Avoid crashing the kernel - try using WARN_ON & recovery code rather than BUG() or BUG_ON() #218: FILE: drivers/dma-buf/dma-buf.c:1313: + BUG_ON(!iosys_map_is_equal(&dmabuf->vmap_ptr, map)); -:1582: WARNING:OBSOLETE: drivers/gpu/drm/tiny/cirrus.c is marked as 'obsolete' in the MAINTAINERS hierarchy. No unnecessary modifications please. -:1585: WARNING:OBSOLETE: drivers/gpu/drm/tiny/cirrus.c is marked as 'obsolete' in the MAINTAINERS hierarchy. No unnecessary modifications please. -:1785: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #1785: FILE: drivers/gpu/drm/ttm/ttm_resource.c:381: + iosys_map_set_vaddr_iomem(&iter_io->dmap, ioremap_wc(mem->bus.offset, -:1790: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #1790: FILE: drivers/gpu/drm/ttm/ttm_resource.c:385: + iosys_map_set_vaddr(&iter_io->dmap, memremap(mem->bus.offset, bus_size, -:1800: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #1800: FILE: drivers/gpu/drm/ttm/ttm_resource.c:393: + iosys_map_set_vaddr_iomem(&iter_io->dmap, ioremap(mem->bus.offset, -:1834: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #1834: FILE: drivers/gpu/drm/ttm/ttm_tt.c:416: + iosys_map_set_vaddr(dmap, kmap_local_page_prot(iter_tt->tt->pages[i], iter_tt->prot)); -:2546: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #2546: deleted file mode 100644 total: 0 errors, 7 warnings, 4 checks, 2275 lines checked
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for dma-buf-map: Rename to iosys-map
== Series Details == Series: dma-buf-map: Rename to iosys-map URL : https://patchwork.freedesktop.org/series/99612/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] [PATCH] drm/i915: Disable unused power wells left enabled by BIOS
Make sure all unused power wells left enabled by BIOS get disabled
during driver loading and system resume.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5028
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/display/intel_display.c | 2 ++
.../drm/i915/display/intel_display_power.c| 31 +++
.../drm/i915/display/intel_display_power.h| 1 +
3 files changed, 34 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index c431076f98a15..df347329d90e5 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -10664,6 +10664,8 @@ intel_modeset_setup_hw_state(struct drm_device *dev,
}
intel_display_power_put(dev_priv, POWER_DOMAIN_INIT, wakeref);
+
+ intel_power_domains_sanitize_state(dev_priv);
}
void intel_display_resume(struct drm_device *dev)
diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
b/drivers/gpu/drm/i915/display/intel_display_power.c
index 369317805d245..d2102cc17bb4c 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power.c
@@ -6213,6 +6213,37 @@ void intel_power_domains_driver_remove(struct
drm_i915_private *i915)
intel_runtime_pm_put(&i915->runtime_pm, wakeref);
}
+/**
+ * intel_power_domains_sanitize_state - sanitize power domains state
+ * @i915: i915 device instance
+ *
+ * Sanitize the power domains state during driver loading and system resume.
+ * The function will disable all display power wells that BIOS has enabled
+ * without a user for it (any user for a power well has taken a reference
+ * on it by the time this function is called, after the state of all the
+ * pipe, encoder, etc. HW resources have been sanitized).
+ */
+void intel_power_domains_sanitize_state(struct drm_i915_private *i915)
+{
+ struct i915_power_domains *power_domains = &i915->power_domains;
+ struct i915_power_well *power_well;
+
+ mutex_lock(&power_domains->lock);
+
+ for_each_power_well_reverse(i915, power_well) {
+ if (power_well->desc->always_on || power_well->count ||
+ !power_well->desc->ops->is_enabled(i915, power_well))
+ continue;
+
+ drm_dbg_kms(&i915->drm,
+ "BIOS left unused %s power well enabled, disabling
it\n",
+ power_well->desc->name);
+ intel_power_well_disable(i915, power_well);
+ }
+
+ mutex_unlock(&power_domains->lock);
+}
+
/**
* intel_power_domains_enable - enable toggling of display power wells
* @i915: i915 device instance
diff --git a/drivers/gpu/drm/i915/display/intel_display_power.h
b/drivers/gpu/drm/i915/display/intel_display_power.h
index 686d18eaa24c8..a985f0e7ef78b 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.h
+++ b/drivers/gpu/drm/i915/display/intel_display_power.h
@@ -219,6 +219,7 @@ void intel_power_domains_disable(struct drm_i915_private
*dev_priv);
void intel_power_domains_suspend(struct drm_i915_private *dev_priv,
enum i915_drm_suspend_mode);
void intel_power_domains_resume(struct drm_i915_private *dev_priv);
+void intel_power_domains_sanitize_state(struct drm_i915_private *dev_priv);
void intel_display_power_suspend_late(struct drm_i915_private *i915);
void intel_display_power_resume_early(struct drm_i915_private *i915);
--
2.27.0
Re: [Intel-gfx] [PATCH i-g-t] intel_gpu_top: Improve error message when insufficient privilege
On 01/02/2022 16:10, Dixit, Ashutosh wrote:
On Tue, 01 Feb 2022 07:19:46 -0800, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Print out end user friendly help text when the running user has
insufficient privilege for accessing system wide performance counters.
Reviewed-by: Ashutosh Dixit
Pushed, thank you!
Regards,
Tvrtko
Signed-off-by: Tvrtko Ursulin
Issue: https://gitlab.freedesktop.org/drm/intel/-/issues/5018
---
tools/intel_gpu_top.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/tools/intel_gpu_top.c b/tools/intel_gpu_top.c
index 81c724d1fe1c..0404a5881b40 100644
--- a/tools/intel_gpu_top.c
+++ b/tools/intel_gpu_top.c
@@ -1761,6 +1761,15 @@ int main(int argc, char **argv)
if (ret) {
fprintf(stderr,
"Failed to initialize PMU! (%s)\n", strerror(errno));
+ if (errno == EACCES && geteuid())
+ fprintf(stderr,
+"\n"
+"When running as a normal user CAP_PERFMON is required to access performance\n"
+"monitoring. See \"man 7 capabilities\", \"man 8 setcap\", or contact your\n"
+"distribution vendor for assistance.\n"
+"\n"
+"More information can be found at 'Perf events and tool security' document:\n"
+"https://www.kernel.org/doc/html/latest/admin-guide/perf-security.html\n";);
ret = EXIT_FAILURE;
goto err;
}
--
2.32.0
Re: [Intel-gfx] [PATCH] drm/i915: Disable unused power wells left enabled by BIOS
On Wed, Feb 02, 2022 at 12:42:49PM +0200, Imre Deak wrote:
> Make sure all unused power wells left enabled by BIOS get disabled
> during driver loading and system resume.
>
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5028
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 2 ++
> .../drm/i915/display/intel_display_power.c| 31 +++
> .../drm/i915/display/intel_display_power.h| 1 +
> 3 files changed, 34 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index c431076f98a15..df347329d90e5 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -10664,6 +10664,8 @@ intel_modeset_setup_hw_state(struct drm_device *dev,
> }
>
> intel_display_power_put(dev_priv, POWER_DOMAIN_INIT, wakeref);
> +
> + intel_power_domains_sanitize_state(dev_priv);
One slight concern is intel_vga_redisable() which is called after
this during resume. Dunno if there's any way we could end up
disabling the power well that houses the VGA logic before actually
turning off the VGA plane?
Hmm. Maybe we should just reorder the intel_modeset_setup_hw_state()
vs. intel_vga_redisable() anyway. We already do those in the opposite
order during driver probe. No idea why we have a different order for
resume.
Apart from that this seems sane enough to me.
Reviewed-by: Ville Syrjälä
> }
>
> void intel_display_resume(struct drm_device *dev)
> diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
> b/drivers/gpu/drm/i915/display/intel_display_power.c
> index 369317805d245..d2102cc17bb4c 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_power.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_power.c
> @@ -6213,6 +6213,37 @@ void intel_power_domains_driver_remove(struct
> drm_i915_private *i915)
> intel_runtime_pm_put(&i915->runtime_pm, wakeref);
> }
>
> +/**
> + * intel_power_domains_sanitize_state - sanitize power domains state
> + * @i915: i915 device instance
> + *
> + * Sanitize the power domains state during driver loading and system resume.
> + * The function will disable all display power wells that BIOS has enabled
> + * without a user for it (any user for a power well has taken a reference
> + * on it by the time this function is called, after the state of all the
> + * pipe, encoder, etc. HW resources have been sanitized).
> + */
> +void intel_power_domains_sanitize_state(struct drm_i915_private *i915)
> +{
> + struct i915_power_domains *power_domains = &i915->power_domains;
> + struct i915_power_well *power_well;
> +
> + mutex_lock(&power_domains->lock);
> +
> + for_each_power_well_reverse(i915, power_well) {
> + if (power_well->desc->always_on || power_well->count ||
> + !power_well->desc->ops->is_enabled(i915, power_well))
> + continue;
> +
> + drm_dbg_kms(&i915->drm,
> + "BIOS left unused %s power well enabled, disabling
> it\n",
> + power_well->desc->name);
> + intel_power_well_disable(i915, power_well);
> + }
> +
> + mutex_unlock(&power_domains->lock);
> +}
> +
> /**
> * intel_power_domains_enable - enable toggling of display power wells
> * @i915: i915 device instance
> diff --git a/drivers/gpu/drm/i915/display/intel_display_power.h
> b/drivers/gpu/drm/i915/display/intel_display_power.h
> index 686d18eaa24c8..a985f0e7ef78b 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_power.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_power.h
> @@ -219,6 +219,7 @@ void intel_power_domains_disable(struct drm_i915_private
> *dev_priv);
> void intel_power_domains_suspend(struct drm_i915_private *dev_priv,
>enum i915_drm_suspend_mode);
> void intel_power_domains_resume(struct drm_i915_private *dev_priv);
> +void intel_power_domains_sanitize_state(struct drm_i915_private *dev_priv);
>
> void intel_display_power_suspend_late(struct drm_i915_private *i915);
> void intel_display_power_resume_early(struct drm_i915_private *i915);
> --
> 2.27.0
--
Ville Syrjälä
Intel
[Intel-gfx] ✗ Fi.CI.BAT: failure for dma-buf-map: Rename to iosys-map
== Series Details ==
Series: dma-buf-map: Rename to iosys-map
URL : https://patchwork.freedesktop.org/series/99612/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11177 -> Patchwork_22153
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_22153 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_22153, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22153/index.html
Participating hosts (48 -> 42)
--
Missing(6): shard-tglu fi-bsw-cyan fi-icl-u2 shard-rkl shard-dg1
fi-bdw-samus
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_22153:
### IGT changes ###
Possible regressions
* igt@i915_selftest@live@hangcheck:
- fi-rkl-guc: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11177/fi-rkl-guc/igt@i915_selftest@l...@hangcheck.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22153/fi-rkl-guc/igt@i915_selftest@l...@hangcheck.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_selftest@live@hangcheck:
- {fi-jsl-1}: [PASS][3] -> [INCOMPLETE][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11177/fi-jsl-1/igt@i915_selftest@l...@hangcheck.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22153/fi-jsl-1/igt@i915_selftest@l...@hangcheck.html
Known issues
Here are the changes found in Patchwork_22153 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_cs_nop@sync-fork-compute0:
- fi-snb-2600:NOTRUN -> [SKIP][5] ([fdo#109271]) +17 similar issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22153/fi-snb-2600/igt@amdgpu/amd_cs_...@sync-fork-compute0.html
* igt@gem_flink_basic@bad-flink:
- fi-skl-6600u: [PASS][6] -> [FAIL][7] ([i915#4547])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11177/fi-skl-6600u/igt@gem_flink_ba...@bad-flink.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22153/fi-skl-6600u/igt@gem_flink_ba...@bad-flink.html
* igt@kms_frontbuffer_tracking@basic:
- fi-cml-u2: [PASS][8] -> [DMESG-WARN][9] ([i915#4269])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11177/fi-cml-u2/igt@kms_frontbuffer_track...@basic.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22153/fi-cml-u2/igt@kms_frontbuffer_track...@basic.html
* igt@runner@aborted:
- fi-skl-6600u: NOTRUN -> [FAIL][10] ([i915#4312])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22153/fi-skl-6600u/igt@run...@aborted.html
Possible fixes
* igt@i915_selftest@live@hangcheck:
- bat-dg1-6: [DMESG-FAIL][11] ([i915#4494] / [i915#4957]) ->
[PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11177/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22153/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
- fi-snb-2600:[INCOMPLETE][13] ([i915#3921]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11177/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22153/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
* igt@kms_frontbuffer_tracking@basic:
- fi-cfl-8109u: [DMESG-FAIL][15] ([i915#295]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11177/fi-cfl-8109u/igt@kms_frontbuffer_track...@basic.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22153/fi-cfl-8109u/igt@kms_frontbuffer_track...@basic.html
* igt@kms_pipe_crc_basic@read-crc-pipe-b:
- fi-cfl-8109u: [DMESG-WARN][17] ([i915#295]) -> [PASS][18] +10
similar issues
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11177/fi-cfl-8109u/igt@kms_pipe_crc_ba...@read-crc-pipe-b.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22153/fi-cfl-8109u/igt@kms_pipe_crc_ba...@read-crc-pipe-b.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[i915#295]: https://gitlab.freedesktop.org/drm/intel/issues/295
[i915#3921]: https://gitlab.freedesktop.org/drm/intel/issues/3921
[i915#3970]: https://gitlab.freedesktop.org/drm/intel/issues/3970
[i915#4269]: https://gitlab.freedesktop.org/drm/intel/issues/4269
[i915#4312]: https://gitlab.
Re: [Intel-gfx] [PATCH 01/21] MAINTAINERS: Add entry for fbdev core
On Mon, 31 Jan 2022 at 21:06, Daniel Vetter wrote: > Ever since Tomi extracted the core code in 2014 it's been defacto me > maintaining this, with help from others from dri-devel and sometimes > Linus (but those are mostly merge conflicts): > > $ git shortlog -ns drivers/video/fbdev/core/ | head -n5 > 35 Daniel Vetter > 23 Linus Torvalds > 10 Hans de Goede > 9 Dave Airlie > 6 Peter Rosin > > I think ideally we'd also record that the various firmware fb drivers > (efifb, vesafb, ...) are also maintained in drm-misc because for the > past few years the patches have either been to fix handover issues > with drm drivers, or caused handover issues with drm drivers. So any > other tree just doesn't make sense. But also, there's plenty of > outdated MAINTAINER entries for these with people and git trees that > haven't been active in years, so maybe let's just leave them alone. > And furthermore distros are now adopting simpledrm as the firmware fb > driver, so hopefully the need to care about the fbdev firmware drivers > will go down going forward. > > Note that drm-misc is group maintained, I expect that to continue like > we've done before, so no new expectations that patches all go through > my hands. That would be silly. This also means I'm happy to put any > other volunteer's name in the M: line, but otherwise git log says I'm > the one who's stuck with this. Acked-by: Daniel Stone
[Intel-gfx] [PATCH 1/4] drm/i915: Move PIPE_CHICKEN RMW out from the vblank evade critical section
From: Ville Syrjälä We don't want any RMWs in the part of the commit that happens under vblank evasion. Eventually we want to use the DSB to handle that and it can't read registers at all. Also reads are just slowing us down needlessly. Let's move the whole PIPE_CHICKEN stuff out from the critical section since we don't have anything there that needs to be syncrhonized with other plane/pipe registers. If we ever need to add such things then we have to move it back, but without doing any reads. TODO: should look into eliminating the RMW anyway... Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_display.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c index c431076f98a1..05713b64d4bc 100644 --- a/drivers/gpu/drm/i915/display/intel_display.c +++ b/drivers/gpu/drm/i915/display/intel_display.c @@ -8121,9 +8121,6 @@ static void intel_pipe_fastset(const struct intel_crtc_state *old_crtc_state, if (DISPLAY_VER(dev_priv) >= 9 || IS_BROADWELL(dev_priv) || IS_HASWELL(dev_priv)) hsw_set_linetime_wm(new_crtc_state); - - if (DISPLAY_VER(dev_priv) >= 11) - icl_set_pipe_chicken(new_crtc_state); } static void commit_pipe_pre_planes(struct intel_atomic_state *state, @@ -8215,6 +8212,10 @@ static void intel_update_crtc(struct intel_atomic_state *state, if (new_crtc_state->update_pipe) intel_encoders_update_pipe(state, crtc); + + if (DISPLAY_VER(dev_priv) >= 11 && + new_crtc_state->update_pipe) + icl_set_pipe_chicken(new_crtc_state); } intel_fbc_update(state, crtc); -- 2.34.1
[Intel-gfx] [PATCH 2/4] drm/i915: Make the pipe/output CSC register writes lockless
From: Ville Syrjälä
The pipe/output CSC register writes don't need to be locked
since all the registers are suitably isolated to their own
cachelines. So eliminate the locks to reduce the overhead
during the vblank evade critical section.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_color.c | 80 +++---
1 file changed, 40 insertions(+), 40 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_color.c
b/drivers/gpu/drm/i915/display/intel_color.c
index de3ded1e327a..a41da9e3f9dc 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -160,29 +160,29 @@ static void ilk_update_pipe_csc(struct intel_crtc *crtc,
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
enum pipe pipe = crtc->pipe;
- intel_de_write(dev_priv, PIPE_CSC_PREOFF_HI(pipe), preoff[0]);
- intel_de_write(dev_priv, PIPE_CSC_PREOFF_ME(pipe), preoff[1]);
- intel_de_write(dev_priv, PIPE_CSC_PREOFF_LO(pipe), preoff[2]);
+ intel_de_write_fw(dev_priv, PIPE_CSC_PREOFF_HI(pipe), preoff[0]);
+ intel_de_write_fw(dev_priv, PIPE_CSC_PREOFF_ME(pipe), preoff[1]);
+ intel_de_write_fw(dev_priv, PIPE_CSC_PREOFF_LO(pipe), preoff[2]);
- intel_de_write(dev_priv, PIPE_CSC_COEFF_RY_GY(pipe),
- coeff[0] << 16 | coeff[1]);
- intel_de_write(dev_priv, PIPE_CSC_COEFF_BY(pipe), coeff[2] << 16);
+ intel_de_write_fw(dev_priv, PIPE_CSC_COEFF_RY_GY(pipe),
+ coeff[0] << 16 | coeff[1]);
+ intel_de_write_fw(dev_priv, PIPE_CSC_COEFF_BY(pipe), coeff[2] << 16);
- intel_de_write(dev_priv, PIPE_CSC_COEFF_RU_GU(pipe),
- coeff[3] << 16 | coeff[4]);
- intel_de_write(dev_priv, PIPE_CSC_COEFF_BU(pipe), coeff[5] << 16);
+ intel_de_write_fw(dev_priv, PIPE_CSC_COEFF_RU_GU(pipe),
+ coeff[3] << 16 | coeff[4]);
+ intel_de_write_fw(dev_priv, PIPE_CSC_COEFF_BU(pipe), coeff[5] << 16);
- intel_de_write(dev_priv, PIPE_CSC_COEFF_RV_GV(pipe),
- coeff[6] << 16 | coeff[7]);
- intel_de_write(dev_priv, PIPE_CSC_COEFF_BV(pipe), coeff[8] << 16);
+ intel_de_write_fw(dev_priv, PIPE_CSC_COEFF_RV_GV(pipe),
+ coeff[6] << 16 | coeff[7]);
+ intel_de_write_fw(dev_priv, PIPE_CSC_COEFF_BV(pipe), coeff[8] << 16);
if (DISPLAY_VER(dev_priv) >= 7) {
- intel_de_write(dev_priv, PIPE_CSC_POSTOFF_HI(pipe),
- postoff[0]);
- intel_de_write(dev_priv, PIPE_CSC_POSTOFF_ME(pipe),
- postoff[1]);
- intel_de_write(dev_priv, PIPE_CSC_POSTOFF_LO(pipe),
- postoff[2]);
+ intel_de_write_fw(dev_priv, PIPE_CSC_POSTOFF_HI(pipe),
+ postoff[0]);
+ intel_de_write_fw(dev_priv, PIPE_CSC_POSTOFF_ME(pipe),
+ postoff[1]);
+ intel_de_write_fw(dev_priv, PIPE_CSC_POSTOFF_LO(pipe),
+ postoff[2]);
}
}
@@ -194,28 +194,28 @@ static void icl_update_output_csc(struct intel_crtc *crtc,
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
enum pipe pipe = crtc->pipe;
- intel_de_write(dev_priv, PIPE_CSC_OUTPUT_PREOFF_HI(pipe), preoff[0]);
- intel_de_write(dev_priv, PIPE_CSC_OUTPUT_PREOFF_ME(pipe), preoff[1]);
- intel_de_write(dev_priv, PIPE_CSC_OUTPUT_PREOFF_LO(pipe), preoff[2]);
+ intel_de_write_fw(dev_priv, PIPE_CSC_OUTPUT_PREOFF_HI(pipe), preoff[0]);
+ intel_de_write_fw(dev_priv, PIPE_CSC_OUTPUT_PREOFF_ME(pipe), preoff[1]);
+ intel_de_write_fw(dev_priv, PIPE_CSC_OUTPUT_PREOFF_LO(pipe), preoff[2]);
- intel_de_write(dev_priv, PIPE_CSC_OUTPUT_COEFF_RY_GY(pipe),
- coeff[0] << 16 | coeff[1]);
- intel_de_write(dev_priv, PIPE_CSC_OUTPUT_COEFF_BY(pipe),
- coeff[2] << 16);
+ intel_de_write_fw(dev_priv, PIPE_CSC_OUTPUT_COEFF_RY_GY(pipe),
+ coeff[0] << 16 | coeff[1]);
+ intel_de_write_fw(dev_priv, PIPE_CSC_OUTPUT_COEFF_BY(pipe),
+ coeff[2] << 16);
- intel_de_write(dev_priv, PIPE_CSC_OUTPUT_COEFF_RU_GU(pipe),
- coeff[3] << 16 | coeff[4]);
- intel_de_write(dev_priv, PIPE_CSC_OUTPUT_COEFF_BU(pipe),
- coeff[5] << 16);
+ intel_de_write_fw(dev_priv, PIPE_CSC_OUTPUT_COEFF_RU_GU(pipe),
+ coeff[3] << 16 | coeff[4]);
+ intel_de_write_fw(dev_priv, PIPE_CSC_OUTPUT_COEFF_BU(pipe),
+ coeff[5] << 16);
- intel_de_write(dev_priv, PIPE_CSC_OUTPUT_COEFF_RV_GV(pipe),
- coeff[6] << 16 | coeff[7]);
- intel_de_write(dev_priv, PIPE_CSC_OUTPUT_COEFF_BV(pipe),
- coeff[8] << 16);
+ intel_de_
[Intel-gfx] [PATCH 3/4] drm/i915: Make the CHV CGM CSC register writes lockless
From: Ville Syrjälä The CHV CGM CSC registers are single buffered and so we may have to write them from the vblank worker, which imposes very tight dealines. Drop the pointless locking for the register accessess to reduce the overhead. All the other registers we bash from the vblank worker (LUTs) were already made lockless earlier. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_color.c | 20 ++-- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_color.c b/drivers/gpu/drm/i915/display/intel_color.c index a41da9e3f9dc..8e05fb40d2bf 100644 --- a/drivers/gpu/drm/i915/display/intel_color.c +++ b/drivers/gpu/drm/i915/display/intel_color.c @@ -377,16 +377,16 @@ static void chv_load_cgm_csc(struct intel_crtc *crtc, coeffs[i] |= (abs_coeff >> 20) & 0xfff; } - intel_de_write(dev_priv, CGM_PIPE_CSC_COEFF01(pipe), - coeffs[1] << 16 | coeffs[0]); - intel_de_write(dev_priv, CGM_PIPE_CSC_COEFF23(pipe), - coeffs[3] << 16 | coeffs[2]); - intel_de_write(dev_priv, CGM_PIPE_CSC_COEFF45(pipe), - coeffs[5] << 16 | coeffs[4]); - intel_de_write(dev_priv, CGM_PIPE_CSC_COEFF67(pipe), - coeffs[7] << 16 | coeffs[6]); - intel_de_write(dev_priv, CGM_PIPE_CSC_COEFF8(pipe), - coeffs[8]); + intel_de_write_fw(dev_priv, CGM_PIPE_CSC_COEFF01(pipe), + coeffs[1] << 16 | coeffs[0]); + intel_de_write_fw(dev_priv, CGM_PIPE_CSC_COEFF23(pipe), + coeffs[3] << 16 | coeffs[2]); + intel_de_write_fw(dev_priv, CGM_PIPE_CSC_COEFF45(pipe), + coeffs[5] << 16 | coeffs[4]); + intel_de_write_fw(dev_priv, CGM_PIPE_CSC_COEFF67(pipe), + coeffs[7] << 16 | coeffs[6]); + intel_de_write_fw(dev_priv, CGM_PIPE_CSC_COEFF8(pipe), + coeffs[8]); } /* convert hw value with given bit_precision to lut property val */ -- 2.34.1
[Intel-gfx] [PATCH 4/4] drm/i915: Drop pointless i830 PIPECONF read
From: Ville Syrjälä
Reading the PIPECONF enable bit out from the hardware
in i9xx_set_pipeconf() on i830 is pointless as the bit should
always be set since we keep both pipes constantly running on
i830. Drop the pointless read and just always keep the bit set.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 05713b64d4bc..9e318341a498 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -3347,13 +3347,11 @@ static void i9xx_set_pipeconf(const struct
intel_crtc_state *crtc_state)
{
struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
- u32 pipeconf;
-
- pipeconf = 0;
+ u32 pipeconf = 0;
/* we keep both pipes enabled on 830 */
if (IS_I830(dev_priv))
- pipeconf |= intel_de_read(dev_priv, PIPECONF(crtc->pipe)) &
PIPECONF_ENABLE;
+ pipeconf |= PIPECONF_ENABLE;
if (crtc_state->double_wide)
pipeconf |= PIPECONF_DOUBLE_WIDE;
--
2.34.1
Re: [Intel-gfx] [PATCH 1/6] drm: add writeback pointers to drm_connector
Hi Kandpal, Thank you for the patch! Yet something to improve: [auto build test ERROR on drm/drm-next] [also build test ERROR on drm-intel/for-linux-next drm-tip/drm-tip v5.17-rc2 next-20220202] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch] url: https://github.com/0day-ci/linux/commits/Kandpal-Suraj/drm-writeback-connector-changes/20220202-164832 base: git://anongit.freedesktop.org/drm/drm drm-next config: alpha-allmodconfig (https://download.01.org/0day-ci/archive/20220202/202202021914.bkeua6fh-...@intel.com/config) compiler: alpha-linux-gcc (GCC) 11.2.0 reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # https://github.com/0day-ci/linux/commit/57ad56d769873f62f87fe432243030ceb1678f87 git remote add linux-review https://github.com/0day-ci/linux git fetch --no-tags linux-review Kandpal-Suraj/drm-writeback-connector-changes/20220202-164832 git checkout 57ad56d769873f62f87fe432243030ceb1678f87 # save the config file to linux build tree mkdir build_dir COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-11.2.0 make.cross O=build_dir ARCH=alpha SHELL=/bin/bash drivers/gpu/drm/arm/ If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot Note: the linux-review/Kandpal-Suraj/drm-writeback-connector-changes/20220202-164832 HEAD 75bbd0a8b1fb58f702279bfbc2fe2d74db8f7028 builds fine. It only hurts bisectability. All errors (new ones prefixed by >>): drivers/gpu/drm/arm/malidp_crtc.c: In function 'malidp_crtc_atomic_check': >> drivers/gpu/drm/arm/malidp_crtc.c:427:47: error: passing argument 1 of >> 'drm_connector_index' from incompatible pointer type >> [-Werror=incompatible-pointer-types] 427 | (1 << drm_connector_index(&malidp->mw_connector.base))) | ^~ | | | struct drm_connector ** In file included from include/drm/drm_modes.h:33, from include/drm/drm_crtc.h:40, from include/drm/drm_atomic.h:31, from drivers/gpu/drm/arm/malidp_crtc.c:14: include/drm/drm_connector.h:1679:76: note: expected 'const struct drm_connector *' but argument is of type 'struct drm_connector **' 1679 | static inline unsigned int drm_connector_index(const struct drm_connector *connector) | ^ cc1: some warnings being treated as errors -- drivers/gpu/drm/arm/malidp_mw.c: In function 'malidp_mw_connector_init': >> drivers/gpu/drm/arm/malidp_mw.c:215:37: error: >> 'malidp->mw_connector.encoder' is a pointer; did you mean to use '->'? 215 | malidp->mw_connector.encoder.possible_crtcs = 1 << drm_crtc_index(&malidp->crtc); | ^ | -> >> drivers/gpu/drm/arm/malidp_mw.c:216:34: error: passing argument 1 of >> 'drm_connector_helper_add' from incompatible pointer type >> [-Werror=incompatible-pointer-types] 216 | drm_connector_helper_add(&malidp->mw_connector.base, | ^~ | | | struct drm_connector ** In file included from include/drm/drm_atomic_helper.h:32, from drivers/gpu/drm/arm/malidp_mw.c:10: include/drm/drm_modeset_helper_vtables.h:1153:67: note: expected 'struct drm_connector *' but argument is of type 'struct drm_connector **' 1153 | static inline void drm_connector_helper_add(struct drm_connector *connector, | ~~^ drivers/gpu/drm/arm/malidp_mw.c: In function 'malidp_mw_atomic_commit': >> drivers/gpu/drm/arm/malidp_mw.c:239:63: error: 'mw_conn->base' is a pointer; >> did you mean to use '->'? 239 | struct drm_connector_state *conn_state = mw_conn->base.state; | ^ | -> cc1: some warnings being treated as errors vim +/drm_connector_index +427 drivers/gpu/drm/arm/malidp_crtc.c 28ce675b747
Re: [Intel-gfx] [PATCH 01/21] MAINTAINERS: Add entry for fbdev core
On 31/01/2022 23:05, Daniel Vetter wrote: Ever since Tomi extracted the core code in 2014 it's been defacto me maintaining this, with help from others from dri-devel and sometimes Linus (but those are mostly merge conflicts): $ git shortlog -ns drivers/video/fbdev/core/ | head -n5 35 Daniel Vetter 23 Linus Torvalds 10 Hans de Goede 9 Dave Airlie 6 Peter Rosin I think ideally we'd also record that the various firmware fb drivers (efifb, vesafb, ...) are also maintained in drm-misc because for the past few years the patches have either been to fix handover issues with drm drivers, or caused handover issues with drm drivers. So any other tree just doesn't make sense. But also, there's plenty of outdated MAINTAINER entries for these with people and git trees that haven't been active in years, so maybe let's just leave them alone. And furthermore distros are now adopting simpledrm as the firmware fb driver, so hopefully the need to care about the fbdev firmware drivers will go down going forward. Note that drm-misc is group maintained, I expect that to continue like we've done before, so no new expectations that patches all go through my hands. That would be silly. This also means I'm happy to put any other volunteer's name in the M: line, but otherwise git log says I'm the one who's stuck with this. Acked-by: Tomi Valkeinen Tomi
Re: [Intel-gfx] [RFC 0/2] Compile out integrated
On Wed, 02 Feb 2022, Tvrtko Ursulin wrote: > On 01/02/2022 17:28, Lucas De Marchi wrote: >> On Tue, Feb 01, 2022 at 07:09:14PM +0200, Jani Nikula wrote: >>> On Tue, 01 Feb 2022, Lucas De Marchi wrote: On Tue, Feb 01, 2022 at 11:15:31AM +, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > Quicky and dirty hack based on some old ideas. Thought maybe the > approach might > interest the Arm port guys. But with IS_GEN_RANGE removed easy gains > are not so > big so meh.. Maybe some more easy wins with IS_DISPLAY_VER but I > haven't looked > into that side. > > 3884664 449681 6720 4341065 423d49 i915.ko.tip > 3599989 429034 6688 4035711 3d947f i915.ko.noigp By these numbers probably it's hard to justify. Another thing to consider is that it's very common to have on the same system both integrated and discrete - doing this would remove at compile time any chance of driving the integrated one. >>> >>> I guess the point was, the arm systems won't have integrated, and it's >>> anyway going to be a separate build. >> >> so probably the focus and argument here should not be about size >> reduction. From patch 1 I see: >> >> +config DRM_I915_INTEGRATED_GPU_SUPPORT >> + bool "Support integrated GPUs" >> + default y >> + depends on DRM_I915 >> + help >> + Include support for integrated GPUs. >> >> If it's something that depends on arch rather than providing an >> option in menuconfig, then I think it could be some interesting >> investigation. However, I can't see how it would help with removing >> some code paths in the driver (e.g. the clflush() calls we were talking >> about in another patch series) since the code elimination would all >> happen at link time. > > Clflush class of problems is yet another orthogonal set of problems. > > Yes, idea was that the Kconfig option would be selected by Arm, or > deselected by x86, whatever. But there is also a case for letting it be > user visible. > > In general, I thought at least, we should look into not > building/deploying binary code for irrelevant hardware on Arm builds. If > that is clear and agreeable then I think the approach how to get there > is really multi-pronged. > > 1) > What you are partly doing with "clflush" type series. Make Arm relevant > code paths actually compile on Arm. > > 2a) > What I sent in this series - it's simple/easy dead code elimination from > a single compilation unit. > > 2b) > *If* we resurrected GRAPHICS_VER check where "ver" is part of the macro, > eg. not doing "if (GRAPHICS_VER <=> N)" but "if (GRAPHICS_VERN)", or "if > IS_GRAPHICS_VER(N, FOREVER)", then the same approach would be more > effective. > > Because if N or range is the macro parameter, we can make it dead code > based on Kconfig. > > This is what I demonstrated few years ago by being able to compile out > ~3rd of a driver when selecting only execlists platforms, AFAIR. > > And which is why I was a bit unhappy this was getting removed not so > long ago. The main problem with that, as well as the Kconfig here, is maintenance. If it's fancy but unused, it's just added complexity for no benefit, just the drawbacks. Every change needs to take the complexity into account. If it's unused and untested, it's just going to bitrot anyway. For example, I think a config option for disabling igfx should have both build and runtime testing in place before we should consider taking on the burden of maintaining it. Otherwise it's just haphazard struggle, and the burden falls on a handful of interested people working on it on the side, occasionally fixing things as they break. And they'll break because nobody else cares. If someone shows up and says i915.ko is too big, they need to be serious enough to invest in maintaining the configurable size reductions, per target platform. BR, Jani. > > 3) > Complex step is putting LTO into use to allow dead code elimination > between compilation units. Think: > > file1.c: > RUNTIME_INFO->needs_blah = IS_PLATFORM && blah > > file2.c > if (RUNTIME_INFO->needs_blah) > ..dead code eliminated by LTO only.. > > Few years ago Andi Kleen had a proof of concept of KBuild LTO but I > don't know what is the status of that. If LTO can be enabled then work > from steps 2a&b automatically works much much better. > > 4) > If LTO is not there yet maybe see how to slightly refactor the code so > that we can completely drop compilation units from the Makefile. Drop > files like gt/intel_ring_submission.c, or similar if we have or can > create candidates. > > Regards, > > Tvrtko -- Jani Nikula, Intel Open Source Graphics Center
[Intel-gfx] [PATCH v2 1/2] drm/i915/vga: switch to use VGA definitions from video/vga.h
The video/vga.h has macros for the VGA registers. Switch to use them. v2: Use direct 0x01 instead of the confusing VGA_SEQ_CLOCK_MODE (Ville) Suggested-by: Matt Roper Cc: Ville Syrjälä Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/display/intel_vga.c | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_vga.c b/drivers/gpu/drm/i915/display/intel_vga.c index fa779f7ea415..b5d058404c14 100644 --- a/drivers/gpu/drm/i915/display/intel_vga.c +++ b/drivers/gpu/drm/i915/display/intel_vga.c @@ -7,6 +7,7 @@ #include #include +#include #include "i915_drv.h" #include "intel_de.h" @@ -34,9 +35,9 @@ void intel_vga_disable(struct drm_i915_private *dev_priv) /* WaEnableVGAAccessThroughIOPort:ctg,elk,ilk,snb,ivb,vlv,hsw */ vga_get_uninterruptible(pdev, VGA_RSRC_LEGACY_IO); - outb(SR01, VGA_SR_INDEX); - sr1 = inb(VGA_SR_DATA); - outb(sr1 | 1 << 5, VGA_SR_DATA); + outb(0x01, VGA_SEQ_I); + sr1 = inb(VGA_SEQ_D); + outb(sr1 | VGA_SR01_SCREEN_OFF, VGA_SEQ_D); vga_put(pdev, VGA_RSRC_LEGACY_IO); udelay(300); @@ -92,7 +93,7 @@ void intel_vga_reset_io_mem(struct drm_i915_private *i915) * and error messages. */ vga_get_uninterruptible(pdev, VGA_RSRC_LEGACY_IO); - outb(inb(VGA_MSR_READ), VGA_MSR_WRITE); + outb(inb(VGA_MIS_R), VGA_MIS_W); vga_put(pdev, VGA_RSRC_LEGACY_IO); } -- 2.30.2
[Intel-gfx] [PATCH v2 2/2] drm/i915: remove VGA register definitions
The only user of the VGA registers has switched to using the definitions in linux/vga.h, so these have become redundant. Remove them. Suggested-by: Matt Roper Cc: Ville Syrjälä Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/i915_reg.h | 41 - 1 file changed, 41 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index 0f36af8dc3a1..48645240d3e7 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -370,48 +370,7 @@ #define GEN6_STOLEN_RESERVED_ENABLE(1 << 0) #define GEN11_STOLEN_RESERVED_ADDR_MASK(0xFFFULL << 20) -/* VGA stuff */ - -#define VGA_ST01_MDA 0x3ba -#define VGA_ST01_CGA 0x3da - #define _VGA_MSR_WRITE _MMIO(0x3c2) -#define VGA_MSR_WRITE 0x3c2 -#define VGA_MSR_READ 0x3cc -#define VGA_MSR_MEM_EN (1 << 1) -#define VGA_MSR_CGA_MODE (1 << 0) - -#define VGA_SR_INDEX 0x3c4 -#define SR01 1 -#define VGA_SR_DATA 0x3c5 - -#define VGA_AR_INDEX 0x3c0 -#define VGA_AR_VID_EN (1 << 5) -#define VGA_AR_DATA_WRITE 0x3c0 -#define VGA_AR_DATA_READ 0x3c1 - -#define VGA_GR_INDEX 0x3ce -#define VGA_GR_DATA 0x3cf -/* GR05 */ -#define VGA_GR_MEM_READ_MODE_SHIFT 3 -#define VGA_GR_MEM_READ_MODE_PLANE 1 -/* GR06 */ -#define VGA_GR_MEM_MODE_MASK 0xc -#define VGA_GR_MEM_MODE_SHIFT 2 -#define VGA_GR_MEM_A_A 0 -#define VGA_GR_MEM_A_B 1 -#define VGA_GR_MEM_B_B7FFF 2 -#define VGA_GR_MEM_B_B 3 - -#define VGA_DACMASK 0x3c6 -#define VGA_DACRX 0x3c7 -#define VGA_DACWX 0x3c8 -#define VGA_DACDATA 0x3c9 - -#define VGA_CR_INDEX_MDA 0x3b4 -#define VGA_CR_DATA_MDA 0x3b5 -#define VGA_CR_INDEX_CGA 0x3d4 -#define VGA_CR_DATA_CGA 0x3d5 #define MI_PREDICATE_SRC0 _MMIO(0x2400) #define MI_PREDICATE_SRC0_UDW _MMIO(0x2400 + 4) -- 2.30.2
Re: [Intel-gfx] [PATCH 3/4] drm/i915/vga: switch to use VGA definitions from video/vga.h
On Wed, 02 Feb 2022, Ville Syrjälä wrote: >> I dropped the ball here a bit. If I respin the same patches, but with >> the above line changed to one of these, is it okay? Which do you prefer? >> >> 1) outb(VGA_SEQ_CLOCK_MODE, VGA_SEQ_I); /* SR01 */ >> >> 2) #define SR01 VGA_SEQ_CLOCK_MODE >> outb(SR01, VGA_SEQ_I); >> >> 3) outb(0x01, VGA_SEQ_I); > > 3 seems like the best option of these. Thanks, v2 on the list. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH v2 1/2] drm/i915/vga: switch to use VGA definitions from video/vga.h
On Wed, Feb 02, 2022 at 01:25:08PM +0200, Jani Nikula wrote: > The video/vga.h has macros for the VGA registers. Switch to use them. > > v2: Use direct 0x01 instead of the confusing VGA_SEQ_CLOCK_MODE (Ville) > > Suggested-by: Matt Roper > Cc: Ville Syrjälä > Signed-off-by: Jani Nikula Series is Reviewed-by: Ville Syrjälä > --- > drivers/gpu/drm/i915/display/intel_vga.c | 9 + > 1 file changed, 5 insertions(+), 4 deletions(-) > > diff --git a/drivers/gpu/drm/i915/display/intel_vga.c > b/drivers/gpu/drm/i915/display/intel_vga.c > index fa779f7ea415..b5d058404c14 100644 > --- a/drivers/gpu/drm/i915/display/intel_vga.c > +++ b/drivers/gpu/drm/i915/display/intel_vga.c > @@ -7,6 +7,7 @@ > #include > > #include > +#include > > #include "i915_drv.h" > #include "intel_de.h" > @@ -34,9 +35,9 @@ void intel_vga_disable(struct drm_i915_private *dev_priv) > > /* WaEnableVGAAccessThroughIOPort:ctg,elk,ilk,snb,ivb,vlv,hsw */ > vga_get_uninterruptible(pdev, VGA_RSRC_LEGACY_IO); > - outb(SR01, VGA_SR_INDEX); > - sr1 = inb(VGA_SR_DATA); > - outb(sr1 | 1 << 5, VGA_SR_DATA); > + outb(0x01, VGA_SEQ_I); > + sr1 = inb(VGA_SEQ_D); > + outb(sr1 | VGA_SR01_SCREEN_OFF, VGA_SEQ_D); > vga_put(pdev, VGA_RSRC_LEGACY_IO); > udelay(300); > > @@ -92,7 +93,7 @@ void intel_vga_reset_io_mem(struct drm_i915_private *i915) >* and error messages. >*/ > vga_get_uninterruptible(pdev, VGA_RSRC_LEGACY_IO); > - outb(inb(VGA_MSR_READ), VGA_MSR_WRITE); > + outb(inb(VGA_MIS_R), VGA_MIS_W); > vga_put(pdev, VGA_RSRC_LEGACY_IO); > } > > -- > 2.30.2 -- Ville Syrjälä Intel
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Disable unused power wells left enabled by BIOS
== Series Details == Series: drm/i915: Disable unused power wells left enabled by BIOS URL : https://patchwork.freedesktop.org/series/99615/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
Re: [Intel-gfx] [PATCH 01/21] MAINTAINERS: Add entry for fbdev core
On Mon, Jan 31, 2022 at 10:05:32PM +0100, Daniel Vetter wrote: > Ever since Tomi extracted the core code in 2014 it's been defacto me > maintaining this, with help from others from dri-devel and sometimes > Linus (but those are mostly merge conflicts): > > $ git shortlog -ns drivers/video/fbdev/core/ | head -n5 > 35 Daniel Vetter > 23 Linus Torvalds > 10 Hans de Goede > 9 Dave Airlie > 6 Peter Rosin > > I think ideally we'd also record that the various firmware fb drivers > (efifb, vesafb, ...) are also maintained in drm-misc because for the > past few years the patches have either been to fix handover issues > with drm drivers, or caused handover issues with drm drivers. So any > other tree just doesn't make sense. But also, there's plenty of > outdated MAINTAINER entries for these with people and git trees that > haven't been active in years, so maybe let's just leave them alone. > And furthermore distros are now adopting simpledrm as the firmware fb > driver, so hopefully the need to care about the fbdev firmware drivers > will go down going forward. > > Note that drm-misc is group maintained, I expect that to continue like > we've done before, so no new expectations that patches all go through > my hands. That would be silly. This also means I'm happy to put any > other volunteer's name in the M: line, but otherwise git log says I'm > the one who's stuck with this. > > Cc: Dave Airlie > Cc: Jani Nikula > Cc: Linus Torvalds > Cc: Linux Fbdev development list > Cc: Pavel Machek > Cc: Sam Ravnborg > Cc: Greg Kroah-Hartman > Cc: Javier Martinez Canillas > Cc: DRI Development > Cc: Linux Kernel Mailing List > Cc: Claudio Suarez > Cc: Tomi Valkeinen > Cc: Geert Uytterhoeven > Cc: Thomas Zimmermann > Cc: Daniel Vetter > Cc: Sven Schnelle > Cc: Gerd Hoffmann > Signed-off-by: Daniel Vetter Acked-by: Maxime Ripard Maxime
Re: [Intel-gfx] [RFC 0/2] Compile out integrated
On 01/02/2022 11:15, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Quicky and dirty hack based on some old ideas. Thought maybe the approach might interest the Arm port guys. But with IS_GEN_RANGE removed easy gains are not so big so meh.. Maybe some more easy wins with IS_DISPLAY_VER but I haven't looked into that side. 3884664 4496816720 4341065 423d49 i915.ko.tip 3599989 4290346688 4035711 3d947f i915.ko.noigp Note debug kconfig so everything is inflated. Whether or not the relative gain would change with production kconfig I am not sure. Non debug build for the record: textdata bss dec hex filename 2188446 205282944 2211918 21c04e i915.ko.tip 1926865 177762944 1947585 1db7c1 i915.ko.noigpu So around ~12% of the driver eliminated as dead code with the easy and incomplete approach. Not bad considering no clean split on Gen12, gen based if-ladder are mostly untouched and no LTO. Regards, Tvrtko
Re: [Intel-gfx] [PATCH] drm/i915: Disable unused power wells left enabled by BIOS
On Wed, Feb 02, 2022 at 01:00:46PM +0200, Ville Syrjälä wrote:
> On Wed, Feb 02, 2022 at 12:42:49PM +0200, Imre Deak wrote:
> > Make sure all unused power wells left enabled by BIOS get disabled
> > during driver loading and system resume.
> >
> > Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5028
> > Signed-off-by: Imre Deak
> > ---
> > drivers/gpu/drm/i915/display/intel_display.c | 2 ++
> > .../drm/i915/display/intel_display_power.c| 31 +++
> > .../drm/i915/display/intel_display_power.h| 1 +
> > 3 files changed, 34 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > index c431076f98a15..df347329d90e5 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -10664,6 +10664,8 @@ intel_modeset_setup_hw_state(struct drm_device *dev,
> > }
> >
> > intel_display_power_put(dev_priv, POWER_DOMAIN_INIT, wakeref);
> > +
> > + intel_power_domains_sanitize_state(dev_priv);
>
> One slight concern is intel_vga_redisable() which is called after
> this during resume. Dunno if there's any way we could end up
> disabling the power well that houses the VGA logic before actually
> turning off the VGA plane?
Yes, it could happen by the time
i915_drm_resume()->intel_display_resume() is called. Though, all the
power wells backing the VGA functionality are also in the INIT domain,
so would have caused a problem already before this patch.
i915_restore_display() also calls intel_vga_redisable(), so I think that
should handle the above scenario (and the second call can be removed as
you suggest below).
> Hmm. Maybe we should just reorder the intel_modeset_setup_hw_state()
> vs. intel_vga_redisable() anyway. We already do those in the opposite
> order during driver probe. No idea why we have a different order for
> resume.
>
> Apart from that this seems sane enough to me.
> Reviewed-by: Ville Syrjälä
>
> > }
> >
> > void intel_display_resume(struct drm_device *dev)
> > diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
> > b/drivers/gpu/drm/i915/display/intel_display_power.c
> > index 369317805d245..d2102cc17bb4c 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display_power.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display_power.c
> > @@ -6213,6 +6213,37 @@ void intel_power_domains_driver_remove(struct
> > drm_i915_private *i915)
> > intel_runtime_pm_put(&i915->runtime_pm, wakeref);
> > }
> >
> > +/**
> > + * intel_power_domains_sanitize_state - sanitize power domains state
> > + * @i915: i915 device instance
> > + *
> > + * Sanitize the power domains state during driver loading and system
> > resume.
> > + * The function will disable all display power wells that BIOS has enabled
> > + * without a user for it (any user for a power well has taken a reference
> > + * on it by the time this function is called, after the state of all the
> > + * pipe, encoder, etc. HW resources have been sanitized).
> > + */
> > +void intel_power_domains_sanitize_state(struct drm_i915_private *i915)
> > +{
> > + struct i915_power_domains *power_domains = &i915->power_domains;
> > + struct i915_power_well *power_well;
> > +
> > + mutex_lock(&power_domains->lock);
> > +
> > + for_each_power_well_reverse(i915, power_well) {
> > + if (power_well->desc->always_on || power_well->count ||
> > + !power_well->desc->ops->is_enabled(i915, power_well))
> > + continue;
> > +
> > + drm_dbg_kms(&i915->drm,
> > + "BIOS left unused %s power well enabled, disabling
> > it\n",
> > + power_well->desc->name);
> > + intel_power_well_disable(i915, power_well);
> > + }
> > +
> > + mutex_unlock(&power_domains->lock);
> > +}
> > +
> > /**
> > * intel_power_domains_enable - enable toggling of display power wells
> > * @i915: i915 device instance
> > diff --git a/drivers/gpu/drm/i915/display/intel_display_power.h
> > b/drivers/gpu/drm/i915/display/intel_display_power.h
> > index 686d18eaa24c8..a985f0e7ef78b 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display_power.h
> > +++ b/drivers/gpu/drm/i915/display/intel_display_power.h
> > @@ -219,6 +219,7 @@ void intel_power_domains_disable(struct
> > drm_i915_private *dev_priv);
> > void intel_power_domains_suspend(struct drm_i915_private *dev_priv,
> > enum i915_drm_suspend_mode);
> > void intel_power_domains_resume(struct drm_i915_private *dev_priv);
> > +void intel_power_domains_sanitize_state(struct drm_i915_private *dev_priv);
> >
> > void intel_display_power_suspend_late(struct drm_i915_private *i915);
> > void intel_display_power_resume_early(struct drm_i915_private *i915);
> > --
> > 2.27.0
>
> --
> Ville Syrjälä
> Intel
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Disable unused power wells left enabled by BIOS
== Series Details == Series: drm/i915: Disable unused power wells left enabled by BIOS URL : https://patchwork.freedesktop.org/series/99615/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11177 -> Patchwork_22154 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_22154 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_22154, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22154/index.html Participating hosts (48 -> 43) -- Missing(5): shard-tglu fi-bsw-cyan shard-rkl shard-dg1 fi-bdw-samus Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_22154: ### IGT changes ### Possible regressions * igt@kms_flip@basic-flip-vs-modeset@c-dp3: - fi-tgl-1115g4: NOTRUN -> [DMESG-WARN][1] +88 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22154/fi-tgl-1115g4/igt@kms_flip@basic-flip-vs-mode...@c-dp3.html Known issues Here are the changes found in Patchwork_22154 that come from known issues: ### IGT changes ### Issues hit * igt@debugfs_test@read_all_entries: - fi-kbl-soraka: [PASS][2] -> [DMESG-WARN][3] ([i915#1982] / [i915#262]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11177/fi-kbl-soraka/igt@debugfs_test@read_all_entries.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22154/fi-kbl-soraka/igt@debugfs_test@read_all_entries.html * igt@gem_huc_copy@huc-copy: - fi-tgl-1115g4: NOTRUN -> [SKIP][4] ([i915#2190]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22154/fi-tgl-1115g4/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@basic: - fi-tgl-1115g4: NOTRUN -> [SKIP][5] ([i915#4613]) +3 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22154/fi-tgl-1115g4/igt@gem_lmem_swapp...@basic.html * igt@i915_module_load@reload: - fi-tgl-1115g4: NOTRUN -> [DMESG-WARN][6] ([i915#1385]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22154/fi-tgl-1115g4/igt@i915_module_l...@reload.html * igt@i915_pm_backlight@basic-brightness: - fi-tgl-1115g4: NOTRUN -> [SKIP][7] ([i915#1155]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22154/fi-tgl-1115g4/igt@i915_pm_backli...@basic-brightness.html * igt@i915_pm_rpm@module-reload: - fi-tgl-1115g4: NOTRUN -> [INCOMPLETE][8] ([i915#1385] / [i915#4006]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22154/fi-tgl-1115g4/igt@i915_pm_...@module-reload.html * igt@i915_selftest@live: - fi-skl-6600u: NOTRUN -> [FAIL][9] ([i915#4547]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22154/fi-skl-6600u/igt@i915_selft...@live.html * igt@i915_selftest@live@execlists: - fi-bsw-nick:[PASS][10] -> [INCOMPLETE][11] ([i915#2940]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11177/fi-bsw-nick/igt@i915_selftest@l...@execlists.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22154/fi-bsw-nick/igt@i915_selftest@l...@execlists.html * igt@kms_chamelium@vga-hpd-fast: - fi-tgl-1115g4: NOTRUN -> [SKIP][12] ([fdo#111827]) +8 similar issues [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22154/fi-tgl-1115g4/igt@kms_chamel...@vga-hpd-fast.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic: - fi-tgl-1115g4: NOTRUN -> [SKIP][13] ([i915#4103]) +1 similar issue [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22154/fi-tgl-1115g4/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html * igt@kms_force_connector_basic@force-load-detect: - fi-tgl-1115g4: NOTRUN -> [SKIP][14] ([fdo#109285]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22154/fi-tgl-1115g4/igt@kms_force_connector_ba...@force-load-detect.html * igt@kms_frontbuffer_tracking@basic: - fi-cml-u2: [PASS][15] -> [DMESG-WARN][16] ([i915#4269]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11177/fi-cml-u2/igt@kms_frontbuffer_track...@basic.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22154/fi-cml-u2/igt@kms_frontbuffer_track...@basic.html * igt@kms_psr@primary_mmap_gtt: - fi-tgl-1115g4: NOTRUN -> [SKIP][17] ([fdo#110189]) +3 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22154/fi-tgl-1115g4/igt@kms_psr@primary_mmap_gtt.html * igt@prime_vgem@basic-userptr: - fi-tgl-1115g4: NOTRUN -> [SKIP][18] ([i915#3301]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22154/fi-tgl-1115g4/igt@prime_v...@basic-userptr.html * i
Re: [Intel-gfx] [RFC 0/2] Compile out integrated
On 02/02/2022 11:20, Jani Nikula wrote: On Wed, 02 Feb 2022, Tvrtko Ursulin wrote: On 01/02/2022 17:28, Lucas De Marchi wrote: On Tue, Feb 01, 2022 at 07:09:14PM +0200, Jani Nikula wrote: On Tue, 01 Feb 2022, Lucas De Marchi wrote: On Tue, Feb 01, 2022 at 11:15:31AM +, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Quicky and dirty hack based on some old ideas. Thought maybe the approach might interest the Arm port guys. But with IS_GEN_RANGE removed easy gains are not so big so meh.. Maybe some more easy wins with IS_DISPLAY_VER but I haven't looked into that side. 3884664 449681 6720 4341065 423d49 i915.ko.tip 3599989 429034 6688 4035711 3d947f i915.ko.noigp By these numbers probably it's hard to justify. Another thing to consider is that it's very common to have on the same system both integrated and discrete - doing this would remove at compile time any chance of driving the integrated one. I guess the point was, the arm systems won't have integrated, and it's anyway going to be a separate build. so probably the focus and argument here should not be about size reduction. From patch 1 I see: +config DRM_I915_INTEGRATED_GPU_SUPPORT + bool "Support integrated GPUs" + default y + depends on DRM_I915 + help + Include support for integrated GPUs. If it's something that depends on arch rather than providing an option in menuconfig, then I think it could be some interesting investigation. However, I can't see how it would help with removing some code paths in the driver (e.g. the clflush() calls we were talking about in another patch series) since the code elimination would all happen at link time. Clflush class of problems is yet another orthogonal set of problems. Yes, idea was that the Kconfig option would be selected by Arm, or deselected by x86, whatever. But there is also a case for letting it be user visible. In general, I thought at least, we should look into not building/deploying binary code for irrelevant hardware on Arm builds. If that is clear and agreeable then I think the approach how to get there is really multi-pronged. 1) What you are partly doing with "clflush" type series. Make Arm relevant code paths actually compile on Arm. 2a) What I sent in this series - it's simple/easy dead code elimination from a single compilation unit. 2b) *If* we resurrected GRAPHICS_VER check where "ver" is part of the macro, eg. not doing "if (GRAPHICS_VER <=> N)" but "if (GRAPHICS_VERN)", or "if IS_GRAPHICS_VER(N, FOREVER)", then the same approach would be more effective. Because if N or range is the macro parameter, we can make it dead code based on Kconfig. This is what I demonstrated few years ago by being able to compile out ~3rd of a driver when selecting only execlists platforms, AFAIR. And which is why I was a bit unhappy this was getting removed not so long ago. The main problem with that, as well as the Kconfig here, is maintenance. If it's fancy but unused, it's just added complexity for no benefit, just the drawbacks. Every change needs to take the complexity into account. If it's unused and untested, it's just going to bitrot anyway. For example, I think a config option for disabling igfx should have both build and runtime testing in place before we should consider taking on the burden of maintaining it. Otherwise it's just haphazard struggle, and the burden falls on a handful of interested people working on it on the side, occasionally fixing things as they break. And they'll break because nobody else cares. If someone shows up and says i915.ko is too big, they need to be serious enough to invest in maintaining the configurable size reductions, per target platform. Yeah no disagreement for the most part. Whether there is a cheap way (as in maintenance/intrusiveness) which brings gains large enough. In my view it is also not a question of "too big" per se, but a question of professional pride of doing things properly, even if it is hard, instead of padding the binaries with dead code and sending them on rounds over the world, to "use electrons" unreachable on uncountable hypothetical customer machines and travel as updates over undersea cables for no use. :D Just because we, sitting on the source/upstream, decided it's too hard. Not pressuring anything though, we are not quite there yet to worry about scale deployments of Intel discrete on !x86. There is time. :) I've thrown some seeds out there, if they don't take, they don't. It is fine to tackle the "make it build and work" steps first. Regards, Tvrtko
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm writeback connector changes
== Series Details == Series: drm writeback connector changes URL : https://patchwork.freedesktop.org/series/99610/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11177_full -> Patchwork_22152_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_22152_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_22152_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Participating hosts (13 -> 13) -- No changes in participating hosts Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_22152_full: ### IGT changes ### Possible regressions * igt@i915_selftest@live@evict: - shard-iclb: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11177/shard-iclb8/igt@i915_selftest@l...@evict.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22152/shard-iclb4/igt@i915_selftest@l...@evict.html Known issues Here are the changes found in Patchwork_22152_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_balancer@parallel-keep-submit-fence: - shard-iclb: [PASS][3] -> [SKIP][4] ([i915#4525]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11177/shard-iclb1/igt@gem_exec_balan...@parallel-keep-submit-fence.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22152/shard-iclb3/igt@gem_exec_balan...@parallel-keep-submit-fence.html * igt@gem_exec_fair@basic-none@vecs0: - shard-kbl: NOTRUN -> [FAIL][5] ([i915#2842]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22152/shard-kbl4/igt@gem_exec_fair@basic-n...@vecs0.html * igt@gem_exec_fair@basic-pace-share@rcs0: - shard-glk: [PASS][6] -> [FAIL][7] ([i915#2842]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11177/shard-glk6/igt@gem_exec_fair@basic-pace-sh...@rcs0.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22152/shard-glk7/igt@gem_exec_fair@basic-pace-sh...@rcs0.html * igt@gem_exec_fair@basic-pace@vcs1: - shard-kbl: [PASS][8] -> [FAIL][9] ([i915#2842]) +1 similar issue [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11177/shard-kbl4/igt@gem_exec_fair@basic-p...@vcs1.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22152/shard-kbl6/igt@gem_exec_fair@basic-p...@vcs1.html * igt@gem_lmem_swapping@parallel-random-engines: - shard-skl: NOTRUN -> [SKIP][10] ([fdo#109271] / [i915#4613]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22152/shard-skl9/igt@gem_lmem_swapp...@parallel-random-engines.html - shard-kbl: NOTRUN -> [SKIP][11] ([fdo#109271] / [i915#4613]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22152/shard-kbl3/igt@gem_lmem_swapp...@parallel-random-engines.html * igt@gem_userptr_blits@dmabuf-sync: - shard-kbl: NOTRUN -> [SKIP][12] ([fdo#109271] / [i915#3323]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22152/shard-kbl3/igt@gem_userptr_bl...@dmabuf-sync.html - shard-skl: NOTRUN -> [SKIP][13] ([fdo#109271] / [i915#3323]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22152/shard-skl9/igt@gem_userptr_bl...@dmabuf-sync.html * igt@gem_userptr_blits@sync-unmap-cycles: - shard-skl: [PASS][14] -> [DMESG-WARN][15] ([i915#1982]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11177/shard-skl4/igt@gem_userptr_bl...@sync-unmap-cycles.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22152/shard-skl9/igt@gem_userptr_bl...@sync-unmap-cycles.html * igt@gen9_exec_parse@allowed-all: - shard-apl: [PASS][16] -> [DMESG-WARN][17] ([i915#1436] / [i915#716]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11177/shard-apl4/igt@gen9_exec_pa...@allowed-all.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22152/shard-apl6/igt@gen9_exec_pa...@allowed-all.html * igt@i915_pm_dc@dc3co-vpb-simulation: - shard-skl: NOTRUN -> [SKIP][18] ([fdo#109271] / [i915#658]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22152/shard-skl9/igt@i915_pm...@dc3co-vpb-simulation.html - shard-kbl: NOTRUN -> [SKIP][19] ([fdo#109271] / [i915#658]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22152/shard-kbl3/igt@i915_pm...@dc3co-vpb-simulation.html * igt@i915_suspend@fence-restore-tiled2untiled: - shard-apl: [PASS][20] -> [DMESG-WARN][21] ([i915#180]) +2 similar issues [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11177/shard-apl4/igt@i915_susp...@fence-restore-tiled2untiled.html [21]: https:/
[Intel-gfx] [RFC PATCH] drm/i915: Fix vma lifetime
It's unclear what reference the initial vma refcount refers to. A vma can
have multiple weak references, the object vma list, the vm's bound list
and the gt's closed_list, and that initial vma refcount can be put from
lookups of all these lists. The problem is that if another user is also
holding another vma refcount, removal of other weak references will not
happen and that initial vma refcount may be put again,
causing refcount underflow.
In addition, putting the initial reference will not stop anyone from
calling i915_vma_close() which may put the vma back on the gt's closed
list, from which it is never removed so when the vma is finally freed,
the list becomes corrupted. From what I can tell this never happens in
the current code, because __i915_vm_close() is never called from gem
context close due to a vm open-count inconsistency which saves us here.
Introduce a selftest that illustrates the problems mentioned above.
Also fix this by re-introducing i915_vma_destroy() which removes all
weak references of the vma and *then* puts the initial vma refcount.
Perhaps a better name would be i915_vma_revoke() or i915_vma_zombify(),
since other callers may still hold a refcount, but with the prospect of
being able to replace that with the object lock in the near future,
let's stick with i915_vma_destroy().
The newly introduced selftest produces the following output without
the introduced fixes:
[ 316.077020] i915: Running i915_vma_mock_selftests/igt_vma_lifetime
[ 316.083261] Refcount = 2. Now closing vm.
[ 316.087708] Refcount = 1. Now closing vma.
[ 316.091858] i915_vma_close() caused list corruption.
[ 316.096824] Refcount = 1. Now freeing obj.
[ 316.101073] Refcount = 0. Now freeing vma.
[ 316.105180] [ cut here ]
[ 316.109819] refcount_t: underflow; use-after-free.
[ 316.114632] WARNING: CPU: 1 PID: 7701 at lib/refcount.c:28
refcount_warn_saturate+0xa6/0xf0
Fixes: 76f9764cc3d5 ("drm/i915: Introduce a vma.kref")
Cc: Chris Wilson
Cc: Imre Deak
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_object.c| 14 +---
.../drm/i915/gem/selftests/i915_gem_mman.c| 4 +-
drivers/gpu/drm/i915/gt/intel_gtt.c | 17 ++--
drivers/gpu/drm/i915/i915_vma.c | 79 ---
drivers/gpu/drm/i915/i915_vma.h | 3 +
drivers/gpu/drm/i915/selftests/i915_vma.c | 69
6 files changed, 152 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index e03e362d320b..78c4cbe82031 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -267,12 +267,6 @@ void __i915_gem_object_pages_fini(struct
drm_i915_gem_object *obj)
if (!list_empty(&obj->vma.list)) {
struct i915_vma *vma;
- /*
-* Note that the vma keeps an object reference while
-* it is active, so it *should* not sleep while we
-* destroy it. Our debug code errs insits it *might*.
-* For the moment, play along.
-*/
spin_lock(&obj->vma.lock);
while ((vma = list_first_entry_or_null(&obj->vma.list,
struct i915_vma,
@@ -280,13 +274,7 @@ void __i915_gem_object_pages_fini(struct
drm_i915_gem_object *obj)
GEM_BUG_ON(vma->obj != obj);
spin_unlock(&obj->vma.lock);
- /* Verify that the vma is unbound under the vm mutex. */
- mutex_lock(&vma->vm->mutex);
- atomic_and(~I915_VMA_PIN_MASK, &vma->flags);
- __i915_vma_unbind(vma);
- mutex_unlock(&vma->vm->mutex);
-
- __i915_vma_put(vma);
+ i915_vma_destroy(vma);
spin_lock(&obj->vma.lock);
}
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
index ba29767348be..af36bffd064b 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
@@ -167,7 +167,7 @@ static int check_partial_mapping(struct drm_i915_gem_object
*obj,
out:
i915_gem_object_lock(obj, NULL);
- __i915_vma_put(vma);
+ i915_vma_destroy(vma);
i915_gem_object_unlock(obj);
return err;
}
@@ -264,7 +264,7 @@ static int check_partial_mappings(struct
drm_i915_gem_object *obj,
return err;
i915_gem_object_lock(obj, NULL);
- __i915_vma_put(vma);
+ i915_vma_destroy(vma);
i915_gem_object_unlock(obj);
if (igt_timeout(end_time,
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.c
b/drivers/gpu/drm/i915/gt/intel_gtt.c
index 46be41
Re: [Intel-gfx] [RFC 0/2] Compile out integrated
On Wed, 02 Feb 2022, Tvrtko Ursulin wrote: > On 02/02/2022 11:20, Jani Nikula wrote: >> On Wed, 02 Feb 2022, Tvrtko Ursulin wrote: >>> On 01/02/2022 17:28, Lucas De Marchi wrote: On Tue, Feb 01, 2022 at 07:09:14PM +0200, Jani Nikula wrote: > On Tue, 01 Feb 2022, Lucas De Marchi wrote: >> On Tue, Feb 01, 2022 at 11:15:31AM +, Tvrtko Ursulin wrote: >>> From: Tvrtko Ursulin >>> >>> Quicky and dirty hack based on some old ideas. Thought maybe the >>> approach might >>> interest the Arm port guys. But with IS_GEN_RANGE removed easy gains >>> are not so >>> big so meh.. Maybe some more easy wins with IS_DISPLAY_VER but I >>> haven't looked >>> into that side. >>> >>> 3884664 449681 6720 4341065 423d49 i915.ko.tip >>> 3599989 429034 6688 4035711 3d947f i915.ko.noigp >> >> By these numbers probably it's hard to justify. Another thing to >> consider >> is that it's very common to have on the same system both >> integrated and discrete - doing this would remove at compile time any >> chance of driving the integrated one. > > I guess the point was, the arm systems won't have integrated, and it's > anyway going to be a separate build. so probably the focus and argument here should not be about size reduction. From patch 1 I see: +config DRM_I915_INTEGRATED_GPU_SUPPORT + bool "Support integrated GPUs" + default y + depends on DRM_I915 + help + Include support for integrated GPUs. If it's something that depends on arch rather than providing an option in menuconfig, then I think it could be some interesting investigation. However, I can't see how it would help with removing some code paths in the driver (e.g. the clflush() calls we were talking about in another patch series) since the code elimination would all happen at link time. >>> >>> Clflush class of problems is yet another orthogonal set of problems. >>> >>> Yes, idea was that the Kconfig option would be selected by Arm, or >>> deselected by x86, whatever. But there is also a case for letting it be >>> user visible. >>> >>> In general, I thought at least, we should look into not >>> building/deploying binary code for irrelevant hardware on Arm builds. If >>> that is clear and agreeable then I think the approach how to get there >>> is really multi-pronged. >>> >>> 1) >>> What you are partly doing with "clflush" type series. Make Arm relevant >>> code paths actually compile on Arm. >>> >>> 2a) >>> What I sent in this series - it's simple/easy dead code elimination from >>> a single compilation unit. >>> >>> 2b) >>> *If* we resurrected GRAPHICS_VER check where "ver" is part of the macro, >>> eg. not doing "if (GRAPHICS_VER <=> N)" but "if (GRAPHICS_VERN)", or "if >>> IS_GRAPHICS_VER(N, FOREVER)", then the same approach would be more >>> effective. >>> >>> Because if N or range is the macro parameter, we can make it dead code >>> based on Kconfig. >>> >>> This is what I demonstrated few years ago by being able to compile out >>> ~3rd of a driver when selecting only execlists platforms, AFAIR. >>> >>> And which is why I was a bit unhappy this was getting removed not so >>> long ago. >> >> The main problem with that, as well as the Kconfig here, is maintenance. >> >> If it's fancy but unused, it's just added complexity for no benefit, >> just the drawbacks. Every change needs to take the complexity into >> account. If it's unused and untested, it's just going to bitrot anyway. >> >> For example, I think a config option for disabling igfx should have both >> build and runtime testing in place before we should consider taking on >> the burden of maintaining it. Otherwise it's just haphazard struggle, >> and the burden falls on a handful of interested people working on it on >> the side, occasionally fixing things as they break. And they'll break >> because nobody else cares. >> >> If someone shows up and says i915.ko is too big, they need to be serious >> enough to invest in maintaining the configurable size reductions, per >> target platform. > > Yeah no disagreement for the most part. > > Whether there is a cheap way (as in maintenance/intrusiveness) which > brings gains large enough. > > In my view it is also not a question of "too big" per se, but a question > of professional pride of doing things properly, even if it is hard, > instead of padding the binaries with dead code and sending them on > rounds over the world, to "use electrons" unreachable on uncountable > hypothetical customer machines and travel as updates over undersea > cables for no use. :D Just because we, sitting on the source/upstream, > decided it's too hard. Well, not because it's too hard, but mostly because of picking the battles? Also a matter of taste in what constitutes as professional pride. If it's worth doing, it's worth doing properly? But I guess
Re: [Intel-gfx] [PATCH 5/6] drm/rcar_du: changes to rcar-du driver resulting from drm_writeback_connector structure changes
Hi Kandpal,
Thank you for the patch.
On Wed, Feb 02, 2022 at 02:24:28PM +0530, Kandpal Suraj wrote:
> Changing rcar_du driver to accomadate the change of
> drm_writeback_connector.base and drm_writeback_connector.encoder
> to a pointer the reason for which is explained in the
> Patch(drm: add writeback pointers to drm_connector).
>
> Signed-off-by: Kandpal Suraj
> ---
> drivers/gpu/drm/rcar-du/rcar_du_crtc.h | 2 ++
> drivers/gpu/drm/rcar-du/rcar_du_writeback.c | 8 +---
> 2 files changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
> b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
> index 66e8839db708..68f387a04502 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
> @@ -72,6 +72,8 @@ struct rcar_du_crtc {
> const char *const *sources;
> unsigned int sources_count;
>
> + struct drm_connector connector;
> + struct drm_encoder encoder;
Those fields are, at best, poorly named. Furthermore, there's no need in
this driver or in other drivers using drm_writeback_connector to create
an encoder or connector manually. Let's not polute all drivers because
i915 doesn't have its abstractions right.
Nack.
> struct drm_writeback_connector writeback;
> };
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_writeback.c
> b/drivers/gpu/drm/rcar-du/rcar_du_writeback.c
> index c79d1259e49b..5b1e83380c47 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_writeback.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_writeback.c
> @@ -200,8 +200,10 @@ int rcar_du_writeback_init(struct rcar_du_device *rcdu,
> {
> struct drm_writeback_connector *wb_conn = &rcrtc->writeback;
>
> - wb_conn->encoder.possible_crtcs = 1 << drm_crtc_index(&rcrtc->crtc);
> - drm_connector_helper_add(&wb_conn->base,
> + wb_conn->base = &rcrtc->connector;
> + wb_conn->encoder = &rcrtc->encoder;
> + wb_conn->encoder->possible_crtcs = 1 << drm_crtc_index(&rcrtc->crtc);
> + drm_connector_helper_add(wb_conn->base,
>&rcar_du_wb_conn_helper_funcs);
>
> return drm_writeback_connector_init(&rcdu->ddev, wb_conn,
> @@ -220,7 +222,7 @@ void rcar_du_writeback_setup(struct rcar_du_crtc *rcrtc,
> struct drm_framebuffer *fb;
> unsigned int i;
>
> - state = rcrtc->writeback.base.state;
> + state = rcrtc->writeback.base->state;
> if (!state || !state->writeback_job)
> return;
>
--
Regards,
Laurent Pinchart
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/4] drm/i915: Move PIPE_CHICKEN RMW out from the vblank evade critical section
== Series Details ==
Series: series starting with [1/4] drm/i915: Move PIPE_CHICKEN RMW out from the
vblank evade critical section
URL : https://patchwork.freedesktop.org/series/99616/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11177 -> Patchwork_22155
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_22155 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_22155, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22155/index.html
Participating hosts (48 -> 43)
--
Additional (1): fi-pnv-d510
Missing(6): shard-tglu fi-tgl-1115g4 fi-bsw-cyan shard-rkl shard-dg1
fi-bdw-samus
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_22155:
### IGT changes ###
Possible regressions
* igt@i915_selftest@live@hangcheck:
- fi-bdw-5557u: NOTRUN -> [INCOMPLETE][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22155/fi-bdw-5557u/igt@i915_selftest@l...@hangcheck.html
Known issues
Here are the changes found in Patchwork_22155 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_flink_basic@bad-flink:
- fi-skl-6600u: [PASS][2] -> [FAIL][3] ([i915#4547])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11177/fi-skl-6600u/igt@gem_flink_ba...@bad-flink.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22155/fi-skl-6600u/igt@gem_flink_ba...@bad-flink.html
* igt@gem_huc_copy@huc-copy:
- fi-pnv-d510:NOTRUN -> [SKIP][4] ([fdo#109271]) +57 similar issues
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22155/fi-pnv-d510/igt@gem_huc_c...@huc-copy.html
* igt@kms_chamelium@vga-edid-read:
- fi-bdw-5557u: NOTRUN -> [SKIP][5] ([fdo#109271] / [fdo#111827]) +8
similar issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22155/fi-bdw-5557u/igt@kms_chamel...@vga-edid-read.html
* igt@kms_frontbuffer_tracking@basic:
- fi-cml-u2: [PASS][6] -> [DMESG-WARN][7] ([i915#4269])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11177/fi-cml-u2/igt@kms_frontbuffer_track...@basic.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22155/fi-cml-u2/igt@kms_frontbuffer_track...@basic.html
* igt@kms_psr@cursor_plane_move:
- fi-bdw-5557u: NOTRUN -> [SKIP][8] ([fdo#109271]) +13 similar issues
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22155/fi-bdw-5557u/igt@kms_psr@cursor_plane_move.html
* igt@runner@aborted:
- fi-skl-6600u: NOTRUN -> [FAIL][9] ([i915#4312])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22155/fi-skl-6600u/igt@run...@aborted.html
Possible fixes
* igt@i915_selftest@live@hangcheck:
- bat-dg1-6: [DMESG-FAIL][10] ([i915#4494] / [i915#4957]) ->
[PASS][11]
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11177/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22155/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
* igt@kms_frontbuffer_tracking@basic:
- fi-cfl-8109u: [DMESG-FAIL][12] ([i915#295]) -> [PASS][13]
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11177/fi-cfl-8109u/igt@kms_frontbuffer_track...@basic.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22155/fi-cfl-8109u/igt@kms_frontbuffer_track...@basic.html
* igt@kms_pipe_crc_basic@read-crc-pipe-b:
- fi-cfl-8109u: [DMESG-WARN][14] ([i915#295]) -> [PASS][15] +10
similar issues
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11177/fi-cfl-8109u/igt@kms_pipe_crc_ba...@read-crc-pipe-b.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22155/fi-cfl-8109u/igt@kms_pipe_crc_ba...@read-crc-pipe-b.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#2582]: https://gitlab.freedesktop.org/drm/intel/issues/2582
[i915#295]: https://gitlab.freedesktop.org/drm/intel/issues/295
[i915#4269]: https://gitlab.freedesktop.org/drm/intel/issues/4269
[i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
[i915#4494]: https://gitlab.freedesktop.org/drm/intel/issues/4494
[i915#4547]: https://gitlab.freedesktop.org/drm/intel/issues/4547
[i915#4898]: https://gitlab.freedesktop.org/drm/intel/issues/4898
[i915#4957]: https://gitlab.freedesktop.org/drm/intel/issues/4957
Build cha
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [v2,1/2] drm/i915/vga: switch to use VGA definitions from video/vga.h
== Series Details == Series: series starting with [v2,1/2] drm/i915/vga: switch to use VGA definitions from video/vga.h URL : https://patchwork.freedesktop.org/series/99617/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
Re: [Intel-gfx] [PATCH 5/6] drm/rcar_du: changes to rcar-du driver resulting from drm_writeback_connector structure changes
On Wed, 02 Feb 2022, Laurent Pinchart wrote:
> Hi Kandpal,
>
> Thank you for the patch.
>
> On Wed, Feb 02, 2022 at 02:24:28PM +0530, Kandpal Suraj wrote:
>> Changing rcar_du driver to accomadate the change of
>> drm_writeback_connector.base and drm_writeback_connector.encoder
>> to a pointer the reason for which is explained in the
>> Patch(drm: add writeback pointers to drm_connector).
>>
>> Signed-off-by: Kandpal Suraj
>> ---
>> drivers/gpu/drm/rcar-du/rcar_du_crtc.h | 2 ++
>> drivers/gpu/drm/rcar-du/rcar_du_writeback.c | 8 +---
>> 2 files changed, 7 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
>> b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
>> index 66e8839db708..68f387a04502 100644
>> --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
>> +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
>> @@ -72,6 +72,8 @@ struct rcar_du_crtc {
>> const char *const *sources;
>> unsigned int sources_count;
>>
>> +struct drm_connector connector;
>> +struct drm_encoder encoder;
>
> Those fields are, at best, poorly named. Furthermore, there's no need in
> this driver or in other drivers using drm_writeback_connector to create
> an encoder or connector manually. Let's not polute all drivers because
> i915 doesn't have its abstractions right.
i915 uses the quite common model for struct inheritance:
struct intel_connector {
struct drm_connector base;
/* ... */
}
Same with at least amd, ast, fsl-dcu, hisilicon, mga200, msm, nouveau,
radeon, tilcdc, and vboxvideo.
We could argue about the relative merits of that abstraction, but I
think the bottom line is that it's popular and the drivers using it are
not going to be persuaded to move away from it.
It's no coincidence that the drivers who've implemented writeback so far
(komeda, mali, rcar-du, vc4, and vkms) do not use the abstraction,
because the drm_writeback_connector midlayer does, forcing the issue.
So I think drm_writeback_connector should *not* use the inheritance
abstraction because it's a midlayer that should leave that option to the
drivers. I think drm_writeback_connector needs to be changed to
accommodate that, and, unfortunately, it means current writeback users
need to be changed as well.
I am not sure, however, if the series at hand is the right
approach. Perhaps writeback can be modified to allocate the stuff for
you if you prefer it that way, as long as the drm_connector is not
embedded in struct drm_writeback_connector.
BR,
Jani.
>
> Nack.
>
>> struct drm_writeback_connector writeback;
>> };
>>
>> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_writeback.c
>> b/drivers/gpu/drm/rcar-du/rcar_du_writeback.c
>> index c79d1259e49b..5b1e83380c47 100644
>> --- a/drivers/gpu/drm/rcar-du/rcar_du_writeback.c
>> +++ b/drivers/gpu/drm/rcar-du/rcar_du_writeback.c
>> @@ -200,8 +200,10 @@ int rcar_du_writeback_init(struct rcar_du_device *rcdu,
>> {
>> struct drm_writeback_connector *wb_conn = &rcrtc->writeback;
>>
>> -wb_conn->encoder.possible_crtcs = 1 << drm_crtc_index(&rcrtc->crtc);
>> -drm_connector_helper_add(&wb_conn->base,
>> +wb_conn->base = &rcrtc->connector;
>> +wb_conn->encoder = &rcrtc->encoder;
>> +wb_conn->encoder->possible_crtcs = 1 << drm_crtc_index(&rcrtc->crtc);
>> +drm_connector_helper_add(wb_conn->base,
>> &rcar_du_wb_conn_helper_funcs);
>>
>> return drm_writeback_connector_init(&rcdu->ddev, wb_conn,
>> @@ -220,7 +222,7 @@ void rcar_du_writeback_setup(struct rcar_du_crtc *rcrtc,
>> struct drm_framebuffer *fb;
>> unsigned int i;
>>
>> -state = rcrtc->writeback.base.state;
>> +state = rcrtc->writeback.base->state;
>> if (!state || !state->writeback_job)
>> return;
>>
--
Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH 2/2] drm/i915/gem: Don't try to map and fence large scanout buffers (v5)
On 02/02/2022 01:11, Vivek Kasireddy wrote:
On platforms capable of allowing 8K (7680 x 4320) modes, pinning 2 or
more framebuffers/scanout buffers results in only one that is mappable/
fenceable. Therefore, pageflipping between these 2 FBs where only one
is mappable/fenceable creates latencies large enough to miss alternate
vblanks thereby producing less optimal framerate.
This mainly happens because when i915_gem_object_pin_to_display_plane()
is called to pin one of the FB objs, the associated vma is identified
as misplaced and therefore i915_vma_unbind() is called which unbinds and
evicts it. This misplaced vma gets subseqently pinned only when
i915_gem_object_ggtt_pin_ww() is called without PIN_MAPPABLE. This
results in a latency of ~10ms and happens every other vblank/repaint cycle.
Therefore, to fix this issue, we try to see if there is space to map
at-least two objects of a given size and return early if there isn't. This
would ensure that we do not try with PIN_MAPPABLE for any objects that
are too big to map thereby preventing unncessary unbind.
Testcase:
Running Weston and weston-simple-egl on an Alderlake_S (ADLS) platform
with a 8K@60 mode results in only ~40 FPS. Since upstream Weston submits
a frame ~7ms before the next vblank, the latencies seen between atomic
commit and flip event are 7, 24 (7 + 16.66), 7, 24. suggesting that
it misses the vblank every other frame.
Here is the ftrace snippet that shows the source of the ~10ms latency:
i915_gem_object_pin_to_display_plane() {
0.102 us |i915_gem_object_set_cache_level();
i915_gem_object_ggtt_pin_ww() {
0.390 us | i915_vma_instance();
0.178 us | i915_vma_misplaced();
i915_vma_unbind() {
__i915_active_wait() {
0.082 us |i915_active_acquire_if_busy();
0.475 us | }
intel_runtime_pm_get() {
0.087 us |intel_runtime_pm_acquire();
0.259 us | }
__i915_active_wait() {
0.085 us |i915_active_acquire_if_busy();
0.240 us | }
__i915_vma_evict() {
ggtt_unbind_vma() {
gen8_ggtt_clear_range() {
10507.255 us |}
10507.689 us | }
10508.516 us | }
v2: Instead of using bigjoiner checks, determine whether a scanout
buffer is too big by checking to see if it is possible to map
two of them into the ggtt.
v3 (Ville):
- Count how many fb objects can be fit into the available holes
instead of checking for a hole twice the object size.
- Take alignment constraints into account.
- Limit this large scanout buffer check to >= Gen 11 platforms.
v4:
- Remove existing heuristic that checks just for size. (Ville)
- Return early if we find space to map at-least two objects. (Tvrtko)
- Slightly update the commit message.
v5: (Tvrtko)
- Rename the function to indicate that the object may be too big to
map into the aperture.
- Account for guard pages while calculating the total size required
for the object.
- Do not subject all objects to the heuristic check and instead
consider objects only of a certain size.
- Do the hole walk using the rbtree.
- Preserve the existing PIN_NONBLOCK logic.
- Drop the PIN_MAPPABLE check while pinning the VMA.
Looks nice and clean. Just one question below. Sorry, it's a consequence
of noticing more when it's nice and clean. :)
Cc: Ville Syrjälä
Cc: Maarten Lankhorst
Cc: Tvrtko Ursulin
Cc: Manasi Navare
Signed-off-by: Vivek Kasireddy
---
drivers/gpu/drm/i915/i915_gem.c | 117
1 file changed, 88 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index e3a2c2a0e156..752fec2b4c60 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -46,6 +46,7 @@
#include "gem/i915_gem_mman.h"
#include "gem/i915_gem_region.h"
#include "gem/i915_gem_userptr.h"
+#include "gem/i915_gem_tiling.h"
#include "gt/intel_engine_user.h"
#include "gt/intel_gt.h"
#include "gt/intel_gt_pm.h"
@@ -876,6 +877,92 @@ static void discard_ggtt_vma(struct i915_vma *vma)
spin_unlock(&obj->vma.lock);
}
+static bool
+i915_gem_object_fits_in_aperture(struct drm_i915_gem_object *obj,
+u64 alignment, u64 flags)
+{
+ struct drm_i915_private *i915 = to_i915(obj->base.dev);
+ struct i915_ggtt *ggtt = to_gt(i915)->ggtt;
+ struct drm_mm_node *hole;
+ u64 hole_start, hole_end, start, end;
+ u64 fence_size, fence_alignment;
+ unsigned int count = 0;
+
+ /*
+* If the required space is larger than the available
+* aperture, we will not able to find a slot for the
+* object and unbinding the object now will be in
+* vain. Worse, doing so may cause us to ping-pong
+* the object in and out of the Global GTT and
+* waste a lot of cycles und
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/2] drm/i915/vga: switch to use VGA definitions from video/vga.h
== Series Details ==
Series: series starting with [v2,1/2] drm/i915/vga: switch to use VGA
definitions from video/vga.h
URL : https://patchwork.freedesktop.org/series/99617/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11177 -> Patchwork_22156
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22156/index.html
Participating hosts (48 -> 41)
--
Missing(7): shard-tglu fi-bsw-cyan fi-icl-u2 fi-kbl-8809g shard-rkl
shard-dg1 fi-bdw-samus
Known issues
Here are the changes found in Patchwork_22156 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_module_load@reload:
- fi-kbl-soraka: [PASS][1] -> [DMESG-WARN][2] ([i915#1982])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11177/fi-kbl-soraka/igt@i915_module_l...@reload.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22156/fi-kbl-soraka/igt@i915_module_l...@reload.html
* igt@i915_selftest@live@requests:
- fi-blb-e6850: [PASS][3] -> [DMESG-FAIL][4] ([i915#4528] /
[i915#5026])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11177/fi-blb-e6850/igt@i915_selftest@l...@requests.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22156/fi-blb-e6850/igt@i915_selftest@l...@requests.html
* igt@kms_frontbuffer_tracking@basic:
- fi-cml-u2: [PASS][5] -> [DMESG-WARN][6] ([i915#4269])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11177/fi-cml-u2/igt@kms_frontbuffer_track...@basic.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22156/fi-cml-u2/igt@kms_frontbuffer_track...@basic.html
* igt@runner@aborted:
- fi-blb-e6850: NOTRUN -> [FAIL][7] ([fdo#109271] / [i915#2403] /
[i915#2426] / [i915#4312])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22156/fi-blb-e6850/igt@run...@aborted.html
Possible fixes
* igt@kms_frontbuffer_tracking@basic:
- fi-cfl-8109u: [DMESG-FAIL][8] ([i915#295]) -> [PASS][9]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11177/fi-cfl-8109u/igt@kms_frontbuffer_track...@basic.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22156/fi-cfl-8109u/igt@kms_frontbuffer_track...@basic.html
* igt@kms_pipe_crc_basic@read-crc-pipe-b:
- fi-cfl-8109u: [DMESG-WARN][10] ([i915#295]) -> [PASS][11] +10
similar issues
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11177/fi-cfl-8109u/igt@kms_pipe_crc_ba...@read-crc-pipe-b.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22156/fi-cfl-8109u/igt@kms_pipe_crc_ba...@read-crc-pipe-b.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#2403]: https://gitlab.freedesktop.org/drm/intel/issues/2403
[i915#2426]: https://gitlab.freedesktop.org/drm/intel/issues/2426
[i915#2582]: https://gitlab.freedesktop.org/drm/intel/issues/2582
[i915#295]: https://gitlab.freedesktop.org/drm/intel/issues/295
[i915#4269]: https://gitlab.freedesktop.org/drm/intel/issues/4269
[i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
[i915#4528]: https://gitlab.freedesktop.org/drm/intel/issues/4528
[i915#4898]: https://gitlab.freedesktop.org/drm/intel/issues/4898
[i915#5026]: https://gitlab.freedesktop.org/drm/intel/issues/5026
Build changes
-
* Linux: CI_DRM_11177 -> Patchwork_22156
CI-20190529: 20190529
CI_DRM_11177: 22db355d36b6c879c506e293b0255bf951df1dff @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_6337: 7c9c034619ef9dbfbfe041fbf3973a1cf1ac7a22 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_22156: 09a1b5c13ec4baa46bf5b2228319044fc8bb6d2e @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
09a1b5c13ec4 drm/i915: remove VGA register definitions
10025a832daa drm/i915/vga: switch to use VGA definitions from video/vga.h
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22156/index.html
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Fix vma lifetime
== Series Details == Series: drm/i915: Fix vma lifetime URL : https://patchwork.freedesktop.org/series/99618/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
Re: [Intel-gfx] [PATCH 5/6] drm/rcar_du: changes to rcar-du driver resulting from drm_writeback_connector structure changes
Hi Jani,
On Wed, Feb 02, 2022 at 03:15:03PM +0200, Jani Nikula wrote:
> On Wed, 02 Feb 2022, Laurent Pinchart wrote:
> > On Wed, Feb 02, 2022 at 02:24:28PM +0530, Kandpal Suraj wrote:
> >> Changing rcar_du driver to accomadate the change of
> >> drm_writeback_connector.base and drm_writeback_connector.encoder
> >> to a pointer the reason for which is explained in the
> >> Patch(drm: add writeback pointers to drm_connector).
> >>
> >> Signed-off-by: Kandpal Suraj
> >> ---
> >> drivers/gpu/drm/rcar-du/rcar_du_crtc.h | 2 ++
> >> drivers/gpu/drm/rcar-du/rcar_du_writeback.c | 8 +---
> >> 2 files changed, 7 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
> >> b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
> >> index 66e8839db708..68f387a04502 100644
> >> --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
> >> +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
> >> @@ -72,6 +72,8 @@ struct rcar_du_crtc {
> >>const char *const *sources;
> >>unsigned int sources_count;
> >>
> >> + struct drm_connector connector;
> >> + struct drm_encoder encoder;
> >
> > Those fields are, at best, poorly named. Furthermore, there's no need in
> > this driver or in other drivers using drm_writeback_connector to create
> > an encoder or connector manually. Let's not polute all drivers because
> > i915 doesn't have its abstractions right.
>
> i915 uses the quite common model for struct inheritance:
>
> struct intel_connector {
> struct drm_connector base;
> /* ... */
> }
>
> Same with at least amd, ast, fsl-dcu, hisilicon, mga200, msm, nouveau,
> radeon, tilcdc, and vboxvideo.
>
> We could argue about the relative merits of that abstraction, but I
> think the bottom line is that it's popular and the drivers using it are
> not going to be persuaded to move away from it.
Nobody said inheritance is bad.
> It's no coincidence that the drivers who've implemented writeback so far
> (komeda, mali, rcar-du, vc4, and vkms) do not use the abstraction,
> because the drm_writeback_connector midlayer does, forcing the issue.
Are you sure it's not a coincidence ? :-)
The encoder and especially connector created by drm_writeback_connector
are there only because KMS requires a drm_encoder and a drm_connector to
be exposed to userspace (and I could argue that using a connector for
writeback is a hack, but that won't change). The connector is "virtual",
I still fail to see why i915 or any other driver would need to wrap it
into something else. The whole point of the drm_writeback_connector
abstraction is that drivers do not have to manage the writeback
drm_connector manually, they shouldn't touch it at all.
> So I think drm_writeback_connector should *not* use the inheritance
> abstraction because it's a midlayer that should leave that option to the
> drivers. I think drm_writeback_connector needs to be changed to
> accommodate that, and, unfortunately, it means current writeback users
> need to be changed as well.
>
> I am not sure, however, if the series at hand is the right
> approach. Perhaps writeback can be modified to allocate the stuff for
> you if you prefer it that way, as long as the drm_connector is not
> embedded in struct drm_writeback_connector.
>
> > Nack.
> >
> >>struct drm_writeback_connector writeback;
> >> };
> >>
> >> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_writeback.c
> >> b/drivers/gpu/drm/rcar-du/rcar_du_writeback.c
> >> index c79d1259e49b..5b1e83380c47 100644
> >> --- a/drivers/gpu/drm/rcar-du/rcar_du_writeback.c
> >> +++ b/drivers/gpu/drm/rcar-du/rcar_du_writeback.c
> >> @@ -200,8 +200,10 @@ int rcar_du_writeback_init(struct rcar_du_device
> >> *rcdu,
> >> {
> >>struct drm_writeback_connector *wb_conn = &rcrtc->writeback;
> >>
> >> - wb_conn->encoder.possible_crtcs = 1 << drm_crtc_index(&rcrtc->crtc);
> >> - drm_connector_helper_add(&wb_conn->base,
> >> + wb_conn->base = &rcrtc->connector;
> >> + wb_conn->encoder = &rcrtc->encoder;
> >> + wb_conn->encoder->possible_crtcs = 1 << drm_crtc_index(&rcrtc->crtc);
> >> + drm_connector_helper_add(wb_conn->base,
> >> &rcar_du_wb_conn_helper_funcs);
> >>
> >>return drm_writeback_connector_init(&rcdu->ddev, wb_conn,
> >> @@ -220,7 +222,7 @@ void rcar_du_writeback_setup(struct rcar_du_crtc
> >> *rcrtc,
> >>struct drm_framebuffer *fb;
> >>unsigned int i;
> >>
> >> - state = rcrtc->writeback.base.state;
> >> + state = rcrtc->writeback.base->state;
> >>if (!state || !state->writeback_job)
> >>return;
> >>
--
Regards,
Laurent Pinchart
Re: [Intel-gfx] [PATCH 5/6] drm/rcar_du: changes to rcar-du driver resulting from drm_writeback_connector structure changes
On Wed, Feb 02, 2022 at 03:15:03PM +0200, Jani Nikula wrote:
> On Wed, 02 Feb 2022, Laurent Pinchart
> wrote:
> > Hi Kandpal,
> >
> > Thank you for the patch.
> >
> > On Wed, Feb 02, 2022 at 02:24:28PM +0530, Kandpal Suraj wrote:
> >> Changing rcar_du driver to accomadate the change of
> >> drm_writeback_connector.base and drm_writeback_connector.encoder
> >> to a pointer the reason for which is explained in the
> >> Patch(drm: add writeback pointers to drm_connector).
> >>
> >> Signed-off-by: Kandpal Suraj
> >> ---
> >> drivers/gpu/drm/rcar-du/rcar_du_crtc.h | 2 ++
> >> drivers/gpu/drm/rcar-du/rcar_du_writeback.c | 8 +---
> >> 2 files changed, 7 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
> >> b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
> >> index 66e8839db708..68f387a04502 100644
> >> --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
> >> +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
> >> @@ -72,6 +72,8 @@ struct rcar_du_crtc {
> >>const char *const *sources;
> >>unsigned int sources_count;
> >>
> >> + struct drm_connector connector;
> >> + struct drm_encoder encoder;
> >
> > Those fields are, at best, poorly named. Furthermore, there's no need in
> > this driver or in other drivers using drm_writeback_connector to create
> > an encoder or connector manually. Let's not polute all drivers because
> > i915 doesn't have its abstractions right.
>
> i915 uses the quite common model for struct inheritance:
>
> struct intel_connector {
> struct drm_connector base;
> /* ... */
> }
>
> Same with at least amd, ast, fsl-dcu, hisilicon, mga200, msm, nouveau,
> radeon, tilcdc, and vboxvideo.
>
> We could argue about the relative merits of that abstraction, but I
> think the bottom line is that it's popular and the drivers using it are
> not going to be persuaded to move away from it.
>
> It's no coincidence that the drivers who've implemented writeback so far
> (komeda, mali, rcar-du, vc4, and vkms) do not use the abstraction,
> because the drm_writeback_connector midlayer does, forcing the issue.
>
> So I think drm_writeback_connector should *not* use the inheritance
> abstraction because it's a midlayer that should leave that option to the
> drivers. I think drm_writeback_connector needs to be changed to
> accommodate that, and, unfortunately, it means current writeback users
> need to be changed as well.
>
> I am not sure, however, if the series at hand is the right
> approach. Perhaps writeback can be modified to allocate the stuff for
> you if you prefer it that way, as long as the drm_connector is not
> embedded in struct drm_writeback_connector.
Maybe it's possible to split out the actual writeback functionality
into a separate lighter struct that then gets embedded into
the current drm_writeback_connector (which would therefore remain
as a midlayer for the drivers that want one). And other drivers
can embed the core writeback struct directly into their own things.
Something like that should perhaps minimize the driver changes for
the current users and we just need to adjust a bunch of things in
drm_writeback.c/etc. to not depend on the midlayer stuff.
--
Ville Syrjälä
Intel
Re: [Intel-gfx] [PATCH 11/20] drm/i915/ttm: tweak priority hint selection
On 1/26/22 16:21, Matthew Auld wrote:
For some reason we are selecting PRIO_HAS_PAGES when we don't have
mm.pages, and vice versa. Perhaps something else is going on here.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
LGTM. Should we add a Fixes: tag here?
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index e60b677ecd54..e4cd6ccf5ab1 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -848,11 +848,9 @@ void i915_ttm_adjust_lru(struct drm_i915_gem_object *obj)
} else if (obj->mm.madv != I915_MADV_WILLNEED) {
bo->priority = I915_TTM_PRIO_PURGE;
} else if (!i915_gem_object_has_pages(obj)) {
- if (bo->priority < I915_TTM_PRIO_HAS_PAGES)
- bo->priority = I915_TTM_PRIO_HAS_PAGES;
+ bo->priority = I915_TTM_PRIO_NO_PAGES;
} else {
- if (bo->priority > I915_TTM_PRIO_NO_PAGES)
- bo->priority = I915_TTM_PRIO_NO_PAGES;
+ bo->priority = I915_TTM_PRIO_HAS_PAGES;
}
ttm_bo_move_to_lru_tail(bo, bo->resource, NULL);
[Intel-gfx] [PATCH v1] drm/i915: fix null pointer dereference
From: Łukasz Bartosik
Asus chromebook CX550 crashes during boot on v5.17-rc1 kernel.
The root cause is null pointer defeference of bi_next
in tgl_get_bw_info() in drivers/gpu/drm/i915/display/intel_bw.c.
BUG: kernel NULL pointer dereference, address: 002e
PGD 0 P4D 0
Oops: 0002 [#1] PREEMPT SMP NOPTI
CPU: 0 PID: 1 Comm: swapper/0 Tainted: G U5.17.0-rc1
Hardware name: Google Delbin/Delbin, BIOS Google_Delbin.13672.156.3 05/14/2021
RIP: 0010:tgl_get_bw_info+0x2de/0x510
...
[2.554467] Call Trace:
[2.554467]
[2.554467] intel_bw_init_hw+0x14a/0x434
[2.554467] ? _printk+0x59/0x73
[2.554467] ? _dev_err+0x77/0x91
[2.554467] i915_driver_hw_probe+0x329/0x33e
[2.554467] i915_driver_probe+0x4c8/0x638
[2.554467] i915_pci_probe+0xf8/0x14e
[2.554467] ? _raw_spin_unlock_irqrestore+0x12/0x2c
[2.554467] pci_device_probe+0xaa/0x142
[2.554467] really_probe+0x13f/0x2f4
[2.554467] __driver_probe_device+0x9e/0xd3
[2.554467] driver_probe_device+0x24/0x7c
[2.554467] __driver_attach+0xba/0xcf
[2.554467] ? driver_attach+0x1f/0x1f
[2.554467] bus_for_each_dev+0x8c/0xc0
[2.554467] bus_add_driver+0x11b/0x1f7
[2.554467] driver_register+0x60/0xea
[2.554467] ? mipi_dsi_bus_init+0x16/0x16
[2.554467] i915_init+0x2c/0xb9
[2.554467] ? mipi_dsi_bus_init+0x16/0x16
[2.554467] do_one_initcall+0x12e/0x2b3
[2.554467] do_initcall_level+0xd6/0xf3
[2.554467] do_initcalls+0x4e/0x79
[2.554467] kernel_init_freeable+0xed/0x14d
[2.554467] ? rest_init+0xc1/0xc1
[2.554467] kernel_init+0x1a/0x120
[2.554467] ret_from_fork+0x1f/0x30
[2.554467]
...
Kernel panic - not syncing: Fatal exception
Fixes: c64a9a7c05be ("drm/i915: Update memory bandwidth formulae")
Signed-off-by: Łukasz Bartosik
---
drivers/gpu/drm/i915/display/intel_bw.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_bw.c
b/drivers/gpu/drm/i915/display/intel_bw.c
index 2da4aacc956b..bd0ed68b7faa 100644
--- a/drivers/gpu/drm/i915/display/intel_bw.c
+++ b/drivers/gpu/drm/i915/display/intel_bw.c
@@ -404,15 +404,17 @@ static int tgl_get_bw_info(struct drm_i915_private
*dev_priv, const struct intel
int clpchgroup;
int j;
- if (i < num_groups - 1)
- bi_next = &dev_priv->max_bw[i + 1];
-
clpchgroup = (sa->deburst * qi.deinterleave / num_channels) <<
i;
- if (i < num_groups - 1 && clpchgroup < clperchgroup)
- bi_next->num_planes = (ipqdepth - clpchgroup) /
clpchgroup + 1;
- else
- bi_next->num_planes = 0;
+ if (i < num_groups - 1) {
+ bi_next = &dev_priv->max_bw[i + 1];
+
+ if (clpchgroup < clperchgroup)
+ bi_next->num_planes = (ipqdepth - clpchgroup) /
+ clpchgroup + 1;
+ else
+ bi_next->num_planes = 0;
+ }
bi->num_qgv_points = qi.num_points;
bi->num_psf_gv_points = qi.num_psf_points;
--
2.35.0.rc2.247.g8bbb082509-goog
Re: [Intel-gfx] [PATCH 1/6] drm: add writeback pointers to drm_connector
On Wed, 2 Feb 2022 at 11:46, Kandpal Suraj wrote:
>
> Changing drm_connector and drm_encoder feilds to pointers in
> drm_writeback_connector as the elements of struct
> drm_writeback_connector are:
> struct drm_writeback_connector {
> struct drm_connector base;
> struct drm_encoder encoder;
> Similarly the elements of intel_encoder and intel_connector
> are:
> struct intel_encoder {
> struct drm_encoder base;
>
> struct intel_connector {
> struct drm_connector base;
>
> The function drm_writeback_connector_init() will initialize the
> drm_connector and drm_encoder and attach them as well.
> Since the drm_connector/encoder are both struct in
> drm_writeback_connector and intel_connector/encoder, we need
> one of them to be a pointer so we can reference them or else we
> will be pointing to 2 seprate instances.
Could you please clarify, why do you want to use intel_connector for
the writeback connector?
I can see a usecase for sharing an encoder between the display and
writback pipelines (and if I'm not mistaken, this is the case for
Abhinav's case).
However, sharing the hardware-backed connector and writeback connector
sounds like a sign of a loose abstraction for me.
Please correct me if I'm wrong and Intel driver would really benefit
from reusing intel_connector as a base for drm_writeback_connector.
> Usually the struct defined in drm framework pointing to any
> struct will be pointer and allocating them and initialization
> will be done with the users.
> Like struct drm_connector and drm_encoder are part of drm
> framework and the users of these such as i915 have included them
> in their struct intel_connector and intel_encoder. Likewise
> struct drm_writeback_connector is a special connector and hence
> is not a user of drm_connector and hence this should be pointers.
>
> Adding drm_writeback_connector to drm_connector so that
> writeback_connector can be fetched from drm_connector as the previous
> container_of method won't work due to change in the feilds of
> drm_connector and drm_encoder in drm_writeback_connector.
>
> Note:The corresponding ripple effect due to the above changes namely in
> two drivers as I can see it komeda and vkms have been dealt with in the
> upcoming patches of this series.
>
> Signed-off-by: Kandpal Suraj
>
> Reviewed-by: Abhinav Kumar
> ---
> drivers/gpu/drm/drm_writeback.c | 19 ++-
> include/drm/drm_connector.h | 3 +++
> include/drm/drm_writeback.h | 6 +++---
> 3 files changed, 16 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_writeback.c b/drivers/gpu/drm/drm_writeback.c
> index dccf4504f1bb..47238db42363 100644
> --- a/drivers/gpu/drm/drm_writeback.c
> +++ b/drivers/gpu/drm/drm_writeback.c
> @@ -87,7 +87,7 @@ static const char
> *drm_writeback_fence_get_driver_name(struct dma_fence *fence)
> struct drm_writeback_connector *wb_connector =
> fence_to_wb_connector(fence);
>
> - return wb_connector->base.dev->driver->name;
> + return wb_connector->base->dev->driver->name;
> }
>
> static const char *
> @@ -177,7 +177,7 @@ int drm_writeback_connector_init(struct drm_device *dev,
> const u32 *formats, int n_formats)
> {
> struct drm_property_blob *blob;
> - struct drm_connector *connector = &wb_connector->base;
> + struct drm_connector *connector = wb_connector->base;
> struct drm_mode_config *config = &dev->mode_config;
> int ret = create_writeback_properties(dev);
>
> @@ -189,14 +189,15 @@ int drm_writeback_connector_init(struct drm_device *dev,
> if (IS_ERR(blob))
> return PTR_ERR(blob);
>
> - drm_encoder_helper_add(&wb_connector->encoder, enc_helper_funcs);
> - ret = drm_encoder_init(dev, &wb_connector->encoder,
> + drm_encoder_helper_add(wb_connector->encoder, enc_helper_funcs);
> + ret = drm_encoder_init(dev, wb_connector->encoder,
>&drm_writeback_encoder_funcs,
>DRM_MODE_ENCODER_VIRTUAL, NULL);
> if (ret)
> goto fail;
>
> connector->interlace_allowed = 0;
> + connector->wb_connector = wb_connector;
>
> ret = drm_connector_init(dev, connector, con_funcs,
> DRM_MODE_CONNECTOR_WRITEBACK);
> @@ -204,7 +205,7 @@ int drm_writeback_connector_init(struct drm_device *dev,
> goto connector_fail;
>
> ret = drm_connector_attach_encoder(connector,
> - &wb_connector->encoder);
> + wb_connector->encoder);
> if (ret)
> goto attach_fail;
>
> @@ -233,7 +234,7 @@ int drm_writeback_connector_init(struct drm_device *dev,
> attach_fail:
> drm_connector_cleanup(connector);
> connector_fail:
> - drm_encoder_cleanup(&wb_connector->encoder);
> + drm_encode
Re: [Intel-gfx] [PATCH 12/20] drm/i915/ttm: make eviction mappable aware
On 1/26/22 16:21, Matthew Auld wrote:
If we need to make room for some some mappable object, then we should
only victimize objects that have one or pages that occupy the visible
portion of LMEM. Let's also create a new priority hint for objects that
are placed in mappable memory, where we know that CPU access was
requested, that way we hopefully victimize these last.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 65 -
1 file changed, 63 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index e4cd6ccf5ab1..8376e4c3d290 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -5,8 +5,10 @@
#include
#include
+#include
#include "i915_drv.h"
+#include "i915_ttm_buddy_manager.h"
#include "intel_memory_region.h"
#include "intel_region_ttm.h"
@@ -20,6 +22,7 @@
#define I915_TTM_PRIO_PURGE 0
#define I915_TTM_PRIO_NO_PAGES 1
#define I915_TTM_PRIO_HAS_PAGES 2
+#define I915_TTM_PRIO_NEEDS_CPU_ACCESS 3
/*
* Size of struct ttm_place vector in on-stack struct ttm_placement allocs
@@ -337,6 +340,7 @@ static bool i915_ttm_eviction_valuable(struct
ttm_buffer_object *bo,
const struct ttm_place *place)
{
struct drm_i915_gem_object *obj = i915_ttm_to_gem(bo);
+ struct ttm_resource *res = bo->resource;
if (!obj)
return false;
@@ -350,7 +354,48 @@ static bool i915_ttm_eviction_valuable(struct
ttm_buffer_object *bo,
return false;
/* Will do for now. Our pinned objects are still on TTM's LRU lists */
- return i915_gem_object_evictable(obj);
+ if (!i915_gem_object_evictable(obj))
+ return false;
+
+ switch (res->mem_type) {
+ case TTM_PL_PRIV: {
We should use the I915_ placements for better readability.
Otherwise Reviewed-by: Thomas Hellström
Re: [Intel-gfx] [PATCH 01/21] MAINTAINERS: Add entry for fbdev core
Acked-by: Alex Deucher On Wed, Feb 2, 2022 at 6:31 AM Maxime Ripard wrote: > > On Mon, Jan 31, 2022 at 10:05:32PM +0100, Daniel Vetter wrote: > > Ever since Tomi extracted the core code in 2014 it's been defacto me > > maintaining this, with help from others from dri-devel and sometimes > > Linus (but those are mostly merge conflicts): > > > > $ git shortlog -ns drivers/video/fbdev/core/ | head -n5 > > 35 Daniel Vetter > > 23 Linus Torvalds > > 10 Hans de Goede > > 9 Dave Airlie > > 6 Peter Rosin > > > > I think ideally we'd also record that the various firmware fb drivers > > (efifb, vesafb, ...) are also maintained in drm-misc because for the > > past few years the patches have either been to fix handover issues > > with drm drivers, or caused handover issues with drm drivers. So any > > other tree just doesn't make sense. But also, there's plenty of > > outdated MAINTAINER entries for these with people and git trees that > > haven't been active in years, so maybe let's just leave them alone. > > And furthermore distros are now adopting simpledrm as the firmware fb > > driver, so hopefully the need to care about the fbdev firmware drivers > > will go down going forward. > > > > Note that drm-misc is group maintained, I expect that to continue like > > we've done before, so no new expectations that patches all go through > > my hands. That would be silly. This also means I'm happy to put any > > other volunteer's name in the M: line, but otherwise git log says I'm > > the one who's stuck with this. > > > > Cc: Dave Airlie > > Cc: Jani Nikula > > Cc: Linus Torvalds > > Cc: Linux Fbdev development list > > Cc: Pavel Machek > > Cc: Sam Ravnborg > > Cc: Greg Kroah-Hartman > > Cc: Javier Martinez Canillas > > Cc: DRI Development > > Cc: Linux Kernel Mailing List > > Cc: Claudio Suarez > > Cc: Tomi Valkeinen > > Cc: Geert Uytterhoeven > > Cc: Thomas Zimmermann > > Cc: Daniel Vetter > > Cc: Sven Schnelle > > Cc: Gerd Hoffmann > > Signed-off-by: Daniel Vetter > > Acked-by: Maxime Ripard > > Maxime
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Fix vma lifetime
== Series Details == Series: drm/i915: Fix vma lifetime URL : https://patchwork.freedesktop.org/series/99618/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11177 -> Patchwork_22157 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_22157 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_22157, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22157/index.html Participating hosts (48 -> 44) -- Additional (2): fi-pnv-d510 bat-dg1-5 Missing(6): shard-tglu fi-bsw-cyan fi-icl-u2 shard-rkl shard-dg1 fi-bdw-samus Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_22157: ### IGT changes ### Possible regressions * igt@i915_selftest@live@hangcheck: - fi-bdw-5557u: NOTRUN -> [INCOMPLETE][1] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22157/fi-bdw-5557u/igt@i915_selftest@l...@hangcheck.html Known issues Here are the changes found in Patchwork_22157 that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_gttfill@basic: - bat-dg1-5: NOTRUN -> [SKIP][2] ([i915#4086]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22157/bat-dg1-5/igt@gem_exec_gttf...@basic.html * igt@gem_flink_basic@bad-flink: - fi-skl-6600u: [PASS][3] -> [FAIL][4] ([i915#4547]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11177/fi-skl-6600u/igt@gem_flink_ba...@bad-flink.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22157/fi-skl-6600u/igt@gem_flink_ba...@bad-flink.html * igt@gem_huc_copy@huc-copy: - fi-pnv-d510:NOTRUN -> [SKIP][5] ([fdo#109271]) +57 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22157/fi-pnv-d510/igt@gem_huc_c...@huc-copy.html * igt@gem_mmap@basic: - bat-dg1-5: NOTRUN -> [SKIP][6] ([i915#4083]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22157/bat-dg1-5/igt@gem_m...@basic.html * igt@gem_mmap_gtt@basic: - bat-dg1-5: NOTRUN -> [SKIP][7] ([i915#4077]) +2 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22157/bat-dg1-5/igt@gem_mmap_...@basic.html * igt@gem_tiled_pread_basic: - bat-dg1-5: NOTRUN -> [SKIP][8] ([i915#4079]) +1 similar issue [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22157/bat-dg1-5/igt@gem_tiled_pread_basic.html * igt@i915_pm_backlight@basic-brightness: - bat-dg1-5: NOTRUN -> [SKIP][9] ([i915#1155]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22157/bat-dg1-5/igt@i915_pm_backli...@basic-brightness.html * igt@i915_pm_rpm@module-reload: - fi-bxt-dsi: [PASS][10] -> [DMESG-WARN][11] ([i915#1982]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11177/fi-bxt-dsi/igt@i915_pm_...@module-reload.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22157/fi-bxt-dsi/igt@i915_pm_...@module-reload.html * igt@i915_selftest@live@gtt: - fi-bdw-5557u: NOTRUN -> [DMESG-FAIL][12] ([i915#3674]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22157/fi-bdw-5557u/igt@i915_selftest@l...@gtt.html * igt@i915_selftest@live@hangcheck: - bat-dg1-5: NOTRUN -> [DMESG-FAIL][13] ([i915#4494] / [i915#4957]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22157/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html - fi-hsw-4770:[PASS][14] -> [INCOMPLETE][15] ([i915#3303]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11177/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22157/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html * igt@i915_selftest@live@requests: - fi-blb-e6850: [PASS][16] -> [DMESG-FAIL][17] ([i915#5026]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11177/fi-blb-e6850/igt@i915_selftest@l...@requests.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22157/fi-blb-e6850/igt@i915_selftest@l...@requests.html * igt@kms_addfb_basic@basic-y-tiled-legacy: - bat-dg1-5: NOTRUN -> [SKIP][18] ([i915#4215]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22157/bat-dg1-5/igt@kms_addfb_ba...@basic-y-tiled-legacy.html * igt@kms_addfb_basic@tile-pitch-mismatch: - bat-dg1-5: NOTRUN -> [SKIP][19] ([i915#4212]) +7 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22157/bat-dg1-5/igt@kms_addfb_ba...@tile-pitch-mismatch.html * igt@kms_chamelium@dp-hpd-fast: - bat-dg1-5: NOTRUN -> [SKIP][20] ([fdo#1118
Re: [Intel-gfx] [PATCH v2] dma-buf-map: Rename to iosys-map
Hello Lucas, On Wed, 2 Feb 2022 at 15:08, Lucas De Marchi wrote: > > On Wed, Feb 02, 2022 at 10:25:28AM +0100, Christian König wrote: > >Am 02.02.22 um 10:11 schrieb Lucas De Marchi: > >>[SNIP] > >>diff --git a/MAINTAINERS b/MAINTAINERS > >>index d03ad8da1f36..112676f11792 100644 > >>--- a/MAINTAINERS > >>+++ b/MAINTAINERS > >>@@ -5675,7 +5675,6 @@ T: git git://anongit.freedesktop.org/drm/drm-misc > >> F: Documentation/driver-api/dma-buf.rst > >> F: drivers/dma-buf/ > >> F: include/linux/*fence.h > > > >Oh, that is not correct to begin with. > > right, include/linux/dma-fence* > > > > >>-F: include/linux/dma-buf* > > > >That here should probably be changed to point directly to > >include/linux/dma-buf.h, but that can come later on. > > thanks for catching that. I will change it on next version and add your > (and any additional) ack. > > Lucas De Marchi > > > > >Feel free to add an Acked-by: Christian König > > to the patch. > > > >If nobody objects I'm going to push it drm-misc-next and provide a > >follow up to cleanup the MAINTAINERS file a bit more. Thank you for the patch; apologies for not being able to respond earlier (was out due to covid, just getting back slowly). With Christian's suggestions, looks good to me as well - feel free to add an Acked-by: Sumit Semwal to the same. > > > >Regards, > >Christian. Best, Sumit. > > > >> F: include/linux/dma-resv.h > >> K: \bdma_(?:buf|fence|resv)\b > >>@@ -9976,6 +9975,13 @@ F: include/linux/iova.h > >> F: include/linux/of_iommu.h > >> F: include/uapi/linux/iommu.h > >>+IOSYS-MAP HELPERS > >>+M: Thomas Zimmermann > >>+L: dri-de...@lists.freedesktop.org > >>+S: Maintained > >>+T: git git://anongit.freedesktop.org/drm/drm-misc > >>+F: include/linux/iosys-map.h > >>+ > >
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: fix null pointer dereference
== Series Details == Series: drm/i915: fix null pointer dereference URL : https://patchwork.freedesktop.org/series/99621/ State : success == Summary == CI Bug Log - changes from CI_DRM_11177 -> Patchwork_22158 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22158/index.html Participating hosts (48 -> 43) -- Additional (1): bat-dg1-5 Missing(6): shard-tglu fi-bsw-cyan fi-icl-u2 shard-rkl shard-dg1 fi-bdw-samus Known issues Here are the changes found in Patchwork_22158 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_cs_nop@sync-fork-compute0: - fi-snb-2600:NOTRUN -> [SKIP][1] ([fdo#109271]) +17 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22158/fi-snb-2600/igt@amdgpu/amd_cs_...@sync-fork-compute0.html * igt@gem_exec_gttfill@basic: - bat-dg1-5: NOTRUN -> [SKIP][2] ([i915#4086]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22158/bat-dg1-5/igt@gem_exec_gttf...@basic.html * igt@gem_exec_suspend@basic-s3@smem: - fi-skl-6600u: [PASS][3] -> [INCOMPLETE][4] ([i915#4547]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11177/fi-skl-6600u/igt@gem_exec_suspend@basic...@smem.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22158/fi-skl-6600u/igt@gem_exec_suspend@basic...@smem.html * igt@gem_mmap@basic: - bat-dg1-5: NOTRUN -> [SKIP][5] ([i915#4083]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22158/bat-dg1-5/igt@gem_m...@basic.html * igt@gem_mmap_gtt@basic: - bat-dg1-5: NOTRUN -> [SKIP][6] ([i915#4077]) +2 similar issues [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22158/bat-dg1-5/igt@gem_mmap_...@basic.html * igt@gem_tiled_pread_basic: - bat-dg1-5: NOTRUN -> [SKIP][7] ([i915#4079]) +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22158/bat-dg1-5/igt@gem_tiled_pread_basic.html * igt@i915_pm_backlight@basic-brightness: - bat-dg1-5: NOTRUN -> [SKIP][8] ([i915#1155]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22158/bat-dg1-5/igt@i915_pm_backli...@basic-brightness.html * igt@i915_selftest@live@hangcheck: - bat-dg1-5: NOTRUN -> [DMESG-FAIL][9] ([i915#4494] / [i915#4957]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22158/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html * igt@kms_addfb_basic@basic-y-tiled-legacy: - bat-dg1-5: NOTRUN -> [SKIP][10] ([i915#4215]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22158/bat-dg1-5/igt@kms_addfb_ba...@basic-y-tiled-legacy.html * igt@kms_addfb_basic@tile-pitch-mismatch: - bat-dg1-5: NOTRUN -> [SKIP][11] ([i915#4212]) +7 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22158/bat-dg1-5/igt@kms_addfb_ba...@tile-pitch-mismatch.html * igt@kms_chamelium@dp-hpd-fast: - bat-dg1-5: NOTRUN -> [SKIP][12] ([fdo#111827]) +8 similar issues [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22158/bat-dg1-5/igt@kms_chamel...@dp-hpd-fast.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic: - bat-dg1-5: NOTRUN -> [SKIP][13] ([i915#4103] / [i915#4213]) +1 similar issue [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22158/bat-dg1-5/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html * igt@kms_force_connector_basic@force-load-detect: - bat-dg1-5: NOTRUN -> [SKIP][14] ([fdo#109285]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22158/bat-dg1-5/igt@kms_force_connector_ba...@force-load-detect.html * igt@kms_psr@primary_page_flip: - bat-dg1-5: NOTRUN -> [SKIP][15] ([i915#1072] / [i915#4078]) +3 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22158/bat-dg1-5/igt@kms_psr@primary_page_flip.html * igt@prime_vgem@basic-fence-flip: - bat-dg1-5: NOTRUN -> [SKIP][16] ([i915#3708]) +3 similar issues [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22158/bat-dg1-5/igt@prime_v...@basic-fence-flip.html * igt@prime_vgem@basic-fence-mmap: - bat-dg1-5: NOTRUN -> [SKIP][17] ([i915#3708] / [i915#4077]) +1 similar issue [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22158/bat-dg1-5/igt@prime_v...@basic-fence-mmap.html * igt@prime_vgem@basic-userptr: - bat-dg1-5: NOTRUN -> [SKIP][18] ([i915#3708] / [i915#4873]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22158/bat-dg1-5/igt@prime_v...@basic-userptr.html * igt@runner@aborted: - fi-skl-6600u: NOTRUN -> [FAIL][19] ([i915#4312]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22158/fi-skl-6600u/igt@run...@aborted.html Possi
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [v2,1/2] drm/i915/vga: switch to use VGA definitions from video/vga.h
== Series Details == Series: series starting with [v2,1/2] drm/i915/vga: switch to use VGA definitions from video/vga.h URL : https://patchwork.freedesktop.org/series/99617/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11177_full -> Patchwork_22156_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_22156_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_22156_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Participating hosts (13 -> 10) -- Missing(3): shard-rkl shard-dg1 shard-tglu Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_22156_full: ### IGT changes ### Possible regressions * igt@gem_ctx_engines@execute-one: - shard-tglb: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11177/shard-tglb5/igt@gem_ctx_engi...@execute-one.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22156/shard-tglb6/igt@gem_ctx_engi...@execute-one.html Known issues Here are the changes found in Patchwork_22156_full that come from known issues: ### CI changes ### Issues hit * boot: - shard-apl: ([PASS][3], [PASS][4], [PASS][5], [PASS][6], [PASS][7], [PASS][8], [PASS][9], [PASS][10], [PASS][11], [PASS][12], [PASS][13], [PASS][14], [PASS][15], [PASS][16], [PASS][17], [PASS][18], [PASS][19], [PASS][20], [PASS][21], [PASS][22], [PASS][23], [PASS][24], [PASS][25], [PASS][26], [PASS][27]) -> ([PASS][28], [PASS][29], [PASS][30], [PASS][31], [PASS][32], [PASS][33], [PASS][34], [PASS][35], [PASS][36], [PASS][37], [PASS][38], [PASS][39], [PASS][40], [PASS][41], [PASS][42], [PASS][43], [PASS][44], [PASS][45], [PASS][46], [PASS][47], [PASS][48], [PASS][49], [FAIL][50], [PASS][51], [PASS][52]) ([i915#4386]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11177/shard-apl8/boot.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11177/shard-apl8/boot.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11177/shard-apl8/boot.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11177/shard-apl8/boot.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11177/shard-apl7/boot.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11177/shard-apl7/boot.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11177/shard-apl7/boot.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11177/shard-apl6/boot.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11177/shard-apl6/boot.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11177/shard-apl6/boot.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11177/shard-apl6/boot.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11177/shard-apl4/boot.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11177/shard-apl4/boot.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11177/shard-apl4/boot.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11177/shard-apl3/boot.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11177/shard-apl3/boot.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11177/shard-apl3/boot.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11177/shard-apl3/boot.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11177/shard-apl2/boot.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11177/shard-apl2/boot.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11177/shard-apl2/boot.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11177/shard-apl2/boot.html [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11177/shard-apl1/boot.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11177/shard-apl1/boot.html [27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11177/shard-apl1/boot.html [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22156/shard-apl8/boot.html [29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22156/shard-apl8/boot.html [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22156/shard-apl8/boot.html [31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22156/shard-apl7/boot.html [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22156/shard-apl7/boot.html [33]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22156/shard-apl7/boot.html [34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22156/shard-apl6/boot.html [35]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22156/shard-apl6/boot.html [36]: https://intel-gfx-ci.01.org/tree/dr
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: fix null pointer dereference
== Series Details == Series: drm/i915: fix null pointer dereference URL : https://patchwork.freedesktop.org/series/99621/ State : success == Summary == CI Bug Log - changes from CI_DRM_11177_full -> Patchwork_22158_full Summary --- **SUCCESS** No regressions found. Participating hosts (13 -> 10) -- Missing(3): shard-rkl shard-dg1 shard-tglu Known issues Here are the changes found in Patchwork_22158_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_balancer@parallel-keep-submit-fence: - shard-iclb: [PASS][1] -> [SKIP][2] ([i915#4525]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11177/shard-iclb1/igt@gem_exec_balan...@parallel-keep-submit-fence.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22158/shard-iclb6/igt@gem_exec_balan...@parallel-keep-submit-fence.html * igt@gem_exec_fair@basic-flow@rcs0: - shard-skl: NOTRUN -> [SKIP][3] ([fdo#109271]) +51 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22158/shard-skl2/igt@gem_exec_fair@basic-f...@rcs0.html * igt@gem_exec_fair@basic-pace@rcs0: - shard-kbl: [PASS][4] -> [FAIL][5] ([i915#2842]) +1 similar issue [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11177/shard-kbl4/igt@gem_exec_fair@basic-p...@rcs0.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22158/shard-kbl6/igt@gem_exec_fair@basic-p...@rcs0.html * igt@gem_lmem_swapping@parallel-random-engines: - shard-skl: NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#4613]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22158/shard-skl9/igt@gem_lmem_swapp...@parallel-random-engines.html - shard-kbl: NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#4613]) +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22158/shard-kbl7/igt@gem_lmem_swapp...@parallel-random-engines.html * igt@gem_pxp@verify-pxp-key-change-after-suspend-resume: - shard-iclb: NOTRUN -> [SKIP][8] ([i915#4270]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22158/shard-iclb3/igt@gem_...@verify-pxp-key-change-after-suspend-resume.html * igt@gem_softpin@allocator-evict-all-engines: - shard-glk: [PASS][9] -> [FAIL][10] ([i915#4171]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11177/shard-glk5/igt@gem_soft...@allocator-evict-all-engines.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22158/shard-glk5/igt@gem_soft...@allocator-evict-all-engines.html * igt@gem_userptr_blits@dmabuf-sync: - shard-kbl: NOTRUN -> [SKIP][11] ([fdo#109271] / [i915#3323]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22158/shard-kbl7/igt@gem_userptr_bl...@dmabuf-sync.html - shard-skl: NOTRUN -> [SKIP][12] ([fdo#109271] / [i915#3323]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22158/shard-skl9/igt@gem_userptr_bl...@dmabuf-sync.html * igt@gem_workarounds@suspend-resume-fd: - shard-kbl: NOTRUN -> [DMESG-WARN][13] ([i915#180]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22158/shard-kbl1/igt@gem_workarou...@suspend-resume-fd.html * igt@gen9_exec_parse@allowed-all: - shard-apl: [PASS][14] -> [DMESG-WARN][15] ([i915#1436] / [i915#716]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11177/shard-apl4/igt@gen9_exec_pa...@allowed-all.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22158/shard-apl7/igt@gen9_exec_pa...@allowed-all.html * igt@i915_pm_dc@dc3co-vpb-simulation: - shard-skl: NOTRUN -> [SKIP][16] ([fdo#109271] / [i915#658]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22158/shard-skl9/igt@i915_pm...@dc3co-vpb-simulation.html * igt@i915_suspend@sysfs-reader: - shard-apl: [PASS][17] -> [DMESG-WARN][18] ([i915#180]) +2 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11177/shard-apl1/igt@i915_susp...@sysfs-reader.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22158/shard-apl6/igt@i915_susp...@sysfs-reader.html * igt@kms_async_flips@alternate-sync-async-flip: - shard-skl: [PASS][19] -> [FAIL][20] ([i915#2521]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11177/shard-skl1/igt@kms_async_fl...@alternate-sync-async-flip.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22158/shard-skl1/igt@kms_async_fl...@alternate-sync-async-flip.html - shard-kbl: [PASS][21] -> [FAIL][22] ([i915#2521]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11177/shard-kbl6/igt@kms_async_fl...@alternate-sync-async-flip.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22158/shard-kbl1/igt@kms_async_fl...@alternate-sync-async-flip.html * igt@kms_big_fb@linear-16bpp-rotate-90:
Re: [Intel-gfx] [PATCH 5/6] drm/rcar_du: changes to rcar-du driver resulting from drm_writeback_connector structure changes
On Wed, 02 Feb 2022, Laurent Pinchart wrote:
> Hi Jani,
>
> On Wed, Feb 02, 2022 at 03:15:03PM +0200, Jani Nikula wrote:
>> On Wed, 02 Feb 2022, Laurent Pinchart wrote:
>> > On Wed, Feb 02, 2022 at 02:24:28PM +0530, Kandpal Suraj wrote:
>> >> Changing rcar_du driver to accomadate the change of
>> >> drm_writeback_connector.base and drm_writeback_connector.encoder
>> >> to a pointer the reason for which is explained in the
>> >> Patch(drm: add writeback pointers to drm_connector).
>> >>
>> >> Signed-off-by: Kandpal Suraj
>> >> ---
>> >> drivers/gpu/drm/rcar-du/rcar_du_crtc.h | 2 ++
>> >> drivers/gpu/drm/rcar-du/rcar_du_writeback.c | 8 +---
>> >> 2 files changed, 7 insertions(+), 3 deletions(-)
>> >>
>> >> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
>> >> b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
>> >> index 66e8839db708..68f387a04502 100644
>> >> --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
>> >> +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
>> >> @@ -72,6 +72,8 @@ struct rcar_du_crtc {
>> >> const char *const *sources;
>> >> unsigned int sources_count;
>> >>
>> >> + struct drm_connector connector;
>> >> + struct drm_encoder encoder;
>> >
>> > Those fields are, at best, poorly named. Furthermore, there's no need in
>> > this driver or in other drivers using drm_writeback_connector to create
>> > an encoder or connector manually. Let's not polute all drivers because
>> > i915 doesn't have its abstractions right.
>>
>> i915 uses the quite common model for struct inheritance:
>>
>> struct intel_connector {
>> struct drm_connector base;
>> /* ... */
>> }
>>
>> Same with at least amd, ast, fsl-dcu, hisilicon, mga200, msm, nouveau,
>> radeon, tilcdc, and vboxvideo.
>>
>> We could argue about the relative merits of that abstraction, but I
>> think the bottom line is that it's popular and the drivers using it are
>> not going to be persuaded to move away from it.
>
> Nobody said inheritance is bad.
>
>> It's no coincidence that the drivers who've implemented writeback so far
>> (komeda, mali, rcar-du, vc4, and vkms) do not use the abstraction,
>> because the drm_writeback_connector midlayer does, forcing the issue.
>
> Are you sure it's not a coincidence ? :-)
>
> The encoder and especially connector created by drm_writeback_connector
> are there only because KMS requires a drm_encoder and a drm_connector to
> be exposed to userspace (and I could argue that using a connector for
> writeback is a hack, but that won't change). The connector is "virtual",
> I still fail to see why i915 or any other driver would need to wrap it
> into something else. The whole point of the drm_writeback_connector
> abstraction is that drivers do not have to manage the writeback
> drm_connector manually, they shouldn't touch it at all.
The thing is, drm_writeback_connector_init() calling
drm_connector_init() on the drm_connector embedded in
drm_writeback_connector leads to that connector being added to the
drm_device's list of connectors. Ditto for the encoder.
All the driver code that handles drm_connectors would need to take into
account they might not be embedded in intel_connector. Throughout the
driver. Ditto for the encoders.
The point is, you can't initialize a connector or an encoder for a
drm_device in isolation of the rest of the driver, even if it were
supposed to be hidden away.
BR,
Jani.
>
>> So I think drm_writeback_connector should *not* use the inheritance
>> abstraction because it's a midlayer that should leave that option to the
>> drivers. I think drm_writeback_connector needs to be changed to
>> accommodate that, and, unfortunately, it means current writeback users
>> need to be changed as well.
>>
>> I am not sure, however, if the series at hand is the right
>> approach. Perhaps writeback can be modified to allocate the stuff for
>> you if you prefer it that way, as long as the drm_connector is not
>> embedded in struct drm_writeback_connector.
>>
>> > Nack.
>> >
>> >> struct drm_writeback_connector writeback;
>> >> };
>> >>
>> >> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_writeback.c
>> >> b/drivers/gpu/drm/rcar-du/rcar_du_writeback.c
>> >> index c79d1259e49b..5b1e83380c47 100644
>> >> --- a/drivers/gpu/drm/rcar-du/rcar_du_writeback.c
>> >> +++ b/drivers/gpu/drm/rcar-du/rcar_du_writeback.c
>> >> @@ -200,8 +200,10 @@ int rcar_du_writeback_init(struct rcar_du_device
>> >> *rcdu,
>> >> {
>> >> struct drm_writeback_connector *wb_conn = &rcrtc->writeback;
>> >>
>> >> - wb_conn->encoder.possible_crtcs = 1 << drm_crtc_index(&rcrtc->crtc);
>> >> - drm_connector_helper_add(&wb_conn->base,
>> >> + wb_conn->base = &rcrtc->connector;
>> >> + wb_conn->encoder = &rcrtc->encoder;
>> >> + wb_conn->encoder->possible_crtcs = 1 << drm_crtc_index(&rcrtc->crtc);
>> >> + drm_connector_helper_add(wb_conn->base,
>> >>&rcar_du_wb_conn_helper_funcs);
>> >>
>> >> return drm_writeback_connector_init(&rcdu->ddev, wb_conn,
>
Re: [Intel-gfx] [PATCH 5/6] drm/rcar_du: changes to rcar-du driver resulting from drm_writeback_connector structure changes
On Wed, 02 Feb 2022, Dmitry Baryshkov wrote:
> On Wed, 2 Feb 2022 at 16:15, Jani Nikula wrote:
>>
>> On Wed, 02 Feb 2022, Laurent Pinchart
>> wrote:
>> > Hi Kandpal,
>> >
>> > Thank you for the patch.
>> >
>> > On Wed, Feb 02, 2022 at 02:24:28PM +0530, Kandpal Suraj wrote:
>> >> Changing rcar_du driver to accomadate the change of
>> >> drm_writeback_connector.base and drm_writeback_connector.encoder
>> >> to a pointer the reason for which is explained in the
>> >> Patch(drm: add writeback pointers to drm_connector).
>> >>
>> >> Signed-off-by: Kandpal Suraj
>> >> ---
>> >> drivers/gpu/drm/rcar-du/rcar_du_crtc.h | 2 ++
>> >> drivers/gpu/drm/rcar-du/rcar_du_writeback.c | 8 +---
>> >> 2 files changed, 7 insertions(+), 3 deletions(-)
>> >>
>> >> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
>> >> b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
>> >> index 66e8839db708..68f387a04502 100644
>> >> --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
>> >> +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
>> >> @@ -72,6 +72,8 @@ struct rcar_du_crtc {
>> >> const char *const *sources;
>> >> unsigned int sources_count;
>> >>
>> >> +struct drm_connector connector;
>> >> +struct drm_encoder encoder;
>> >
>> > Those fields are, at best, poorly named. Furthermore, there's no need in
>> > this driver or in other drivers using drm_writeback_connector to create
>> > an encoder or connector manually. Let's not polute all drivers because
>> > i915 doesn't have its abstractions right.
>>
>> i915 uses the quite common model for struct inheritance:
>>
>> struct intel_connector {
>> struct drm_connector base;
>> /* ... */
>> }
>>
>> Same with at least amd, ast, fsl-dcu, hisilicon, mga200, msm, nouveau,
>> radeon, tilcdc, and vboxvideo.
>
> For the reference. msm does not wrap drm_connector into any _common_
> structure, which is used internally.
>
>> We could argue about the relative merits of that abstraction, but I
>> think the bottom line is that it's popular and the drivers using it are
>> not going to be persuaded to move away from it.
>
> As I wrote earlier, I am not sure if these drivers would try using
> their drm_connector subclass for writeback.
> ast: ast_connector = drm_connector + respective i2c adapter for EDID,
> not needed for WB
> fsl-dcu: fsl_dcu_drm_connector = drm_connector + drm_encoder pointer +
> drm_panel. Not needed for WB
> hisilicon, mgag200: same as ast
> tilcdc: same as fsl-dcu
> vboxdrv: the only driver that may possibly benefit from using
> vbox_connector in the writeback support, as the connector is bare
> drm_connector + crtc pointer + hints (width, height, disconnected).
>
> I have left amd, nouveau and radeon out of this list, too complex to
> analyze in several minutes.
>
> I'd second the proposal of supporting optional drm_encoder for
> drm_writeback_connector (as the crtc/encoder split can be vague), but
> I do not see the benefit for the drivers to use their own
> drm_connector subclass for drm_writeback.
If a driver uses inheritance throughout the driver, and a *different*
subclass gets introduced into the mix, you need to add a ton of checks
all over the place when you cast the superclass pointer to the subclass.
The connector/encoder funcs you do have to pass to
drm_writeback_connector_init() can't use any of the shared driver
infrastructure that assume a certain inheritance.
See also my reply to Laurent [1].
> It well might be that we all misunderstand your design. Do you have a
> complete intel drm_writeback implementation based on this patchset? It
> would be easier to judge if the approach is correct seeing your
> target.
That would be up to Suraj Kandpal.
BR,
Jani.
[1] https://lore.kernel.org/r/87v8xxs2hz@intel.com
>
>>
>> It's no coincidence that the drivers who've implemented writeback so far
>> (komeda, mali, rcar-du, vc4, and vkms) do not use the abstraction,
>> because the drm_writeback_connector midlayer does, forcing the issue.
>>
>> So I think drm_writeback_connector should *not* use the inheritance
>> abstraction because it's a midlayer that should leave that option to the
>> drivers. I think drm_writeback_connector needs to be changed to
>> accommodate that, and, unfortunately, it means current writeback users
>> need to be changed as well.
>>
>> I am not sure, however, if the series at hand is the right
>> approach. Perhaps writeback can be modified to allocate the stuff for
>> you if you prefer it that way, as long as the drm_connector is not
>> embedded in struct drm_writeback_connector.
--
Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH v2 1/2] drm/i915/vga: switch to use VGA definitions from video/vga.h
On Wed, 02 Feb 2022, Ville Syrjälä wrote: > On Wed, Feb 02, 2022 at 01:25:08PM +0200, Jani Nikula wrote: >> The video/vga.h has macros for the VGA registers. Switch to use them. >> >> v2: Use direct 0x01 instead of the confusing VGA_SEQ_CLOCK_MODE (Ville) >> >> Suggested-by: Matt Roper >> Cc: Ville Syrjälä >> Signed-off-by: Jani Nikula > > Series is > Reviewed-by: Ville Syrjälä Thanks, pushed. BR, Jani. > >> --- >> drivers/gpu/drm/i915/display/intel_vga.c | 9 + >> 1 file changed, 5 insertions(+), 4 deletions(-) >> >> diff --git a/drivers/gpu/drm/i915/display/intel_vga.c >> b/drivers/gpu/drm/i915/display/intel_vga.c >> index fa779f7ea415..b5d058404c14 100644 >> --- a/drivers/gpu/drm/i915/display/intel_vga.c >> +++ b/drivers/gpu/drm/i915/display/intel_vga.c >> @@ -7,6 +7,7 @@ >> #include >> >> #include >> +#include >> >> #include "i915_drv.h" >> #include "intel_de.h" >> @@ -34,9 +35,9 @@ void intel_vga_disable(struct drm_i915_private *dev_priv) >> >> /* WaEnableVGAAccessThroughIOPort:ctg,elk,ilk,snb,ivb,vlv,hsw */ >> vga_get_uninterruptible(pdev, VGA_RSRC_LEGACY_IO); >> -outb(SR01, VGA_SR_INDEX); >> -sr1 = inb(VGA_SR_DATA); >> -outb(sr1 | 1 << 5, VGA_SR_DATA); >> +outb(0x01, VGA_SEQ_I); >> +sr1 = inb(VGA_SEQ_D); >> +outb(sr1 | VGA_SR01_SCREEN_OFF, VGA_SEQ_D); >> vga_put(pdev, VGA_RSRC_LEGACY_IO); >> udelay(300); >> >> @@ -92,7 +93,7 @@ void intel_vga_reset_io_mem(struct drm_i915_private *i915) >> * and error messages. >> */ >> vga_get_uninterruptible(pdev, VGA_RSRC_LEGACY_IO); >> -outb(inb(VGA_MSR_READ), VGA_MSR_WRITE); >> +outb(inb(VGA_MIS_R), VGA_MIS_W); >> vga_put(pdev, VGA_RSRC_LEGACY_IO); >> } >> >> -- >> 2.30.2 -- Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [RFC 0/2] Compile out integrated
On Wed, Feb 02, 2022 at 10:26:46AM +, Tvrtko Ursulin wrote: On 01/02/2022 17:28, Lucas De Marchi wrote: On Tue, Feb 01, 2022 at 07:09:14PM +0200, Jani Nikula wrote: On Tue, 01 Feb 2022, Lucas De Marchi wrote: On Tue, Feb 01, 2022 at 11:15:31AM +, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Quicky and dirty hack based on some old ideas. Thought maybe the approach might interest the Arm port guys. But with IS_GEN_RANGE removed easy gains are not so big so meh.. Maybe some more easy wins with IS_DISPLAY_VER but I haven't looked into that side. 3884664 449681 6720 4341065 423d49 i915.ko.tip 3599989 429034 6688 4035711 3d947f i915.ko.noigp By these numbers probably it's hard to justify. Another thing to consider is that it's very common to have on the same system both integrated and discrete - doing this would remove at compile time any chance of driving the integrated one. I guess the point was, the arm systems won't have integrated, and it's anyway going to be a separate build. so probably the focus and argument here should not be about size reduction. From patch 1 I see: +config DRM_I915_INTEGRATED_GPU_SUPPORT + bool "Support integrated GPUs" + default y + depends on DRM_I915 + help + Include support for integrated GPUs. If it's something that depends on arch rather than providing an option in menuconfig, then I think it could be some interesting investigation. However, I can't see how it would help with removing some code paths in the driver (e.g. the clflush() calls we were talking about in another patch series) since the code elimination would all happen at link time. Clflush class of problems is yet another orthogonal set of problems. Yes, idea was that the Kconfig option would be selected by Arm, or deselected by x86, whatever. But there is also a case for letting it be user visible. In general, I thought at least, we should look into not building/deploying binary code for irrelevant hardware on Arm builds. If that is clear and agreeable then I think the approach how to get there is really multi-pronged. 1) What you are partly doing with "clflush" type series. Make Arm relevant code paths actually compile on Arm. to be clear, the goal is to be more architecture independent and this is being tested with arm64. 2a) What I sent in this series - it's simple/easy dead code elimination from a single compilation unit. 2b) *If* we resurrected GRAPHICS_VER check where "ver" is part of the macro, eg. not doing "if (GRAPHICS_VER <=> N)" but "if (GRAPHICS_VERN)", or "if IS_GRAPHICS_VER(N, FOREVER)", then the same approach would be more effective. Because if N or range is the macro parameter, we can make it dead code based on Kconfig. yes I remember that. But when it was done the IS_GRAPHICS_VER() was already not much used. I doubt the handful places it was used in would change much of the overall picture we had at that point. This is what I demonstrated few years ago by being able to compile out ~3rd of a driver when selecting only execlists platforms, AFAIR. And which is why I was a bit unhappy this was getting removed not so long ago. 3) Complex step is putting LTO into use to allow dead code elimination between compilation units. Think: file1.c: RUNTIME_INFO->needs_blah = IS_PLATFORM && blah file2.c if (RUNTIME_INFO->needs_blah) ..dead code eliminated by LTO only.. Few years ago Andi Kleen had a proof of concept of KBuild LTO but I don't know what is the status of that. If LTO can be enabled then work from steps 2a&b automatically works much much better. 4) If LTO is not there yet maybe see how to slightly refactor the code so that we can completely drop compilation units from the Makefile. Drop files like gt/intel_ring_submission.c, or similar if we have or can create candidates. I think this is something we have to do and to go after. I think it's more future-proof to organize the code to have a better separation of platforms, instead of relying on the linker to do the dead code elimination based on user selection. I'm fine with compiling out stuff on i915 right now because "this can only and will ever (as far as we know) work on x86". I'm more reluctant about adding a build option though. For the same reasons Jani mentioned and that it suddenly may open the doors for a matrix of configuration (e.g. build with/without display, or rc6, or dsi, or name-the-feature-you-dont-want). Lucas De Marchi Regards, Tvrtko
Re: [Intel-gfx] [PATCH v2 4/4] drm/i915/: Re-work clflush_write32
As far as I know, we haven't gotten to the arm implementation yet, since
we are trying to get i915 compile for arm without using random ifdefs
and dummy functions.
"Noob question - why is i915 the only driver calling it? Do other GPUs
never need to flush CPU cache?"
Unfortunately I don't have enough expertise to comfortable answer this
question. Maybe someone else can chime in here? Lucas? Matt?
On 2022-02-01 8:32 a.m., Tvrtko Ursulin wrote:
On 01/02/2022 15:41, Michael Cheng wrote:
Ah, thanks for the clarification! While discussion goes on about the
route you suggested, could we land these patches (after addressing
the reviews) to unblock compiling i915 on arm?
I am 60-40 to no, since follow up can be hard. I'd prefer a little bit
of discussion before merging.
Also, what will be the Arm implementation of drm_clflush_virt_range?
Noob question - why is i915 the only driver calling it? Do other GPUs
never need to flush CPU cache?
Regards,
Tvrtko
On 2022-02-01 1:25 a.m., Tvrtko Ursulin wrote:
On 31/01/2022 17:02, Michael Cheng wrote:
Hey Tvrtko,
Are you saying when adding drm_clflush_virt_range(addr,
sizeof(addr), this function forces an x86 code path only? If that
is the case, drm_clflush_virt_range(addr, sizeof(addr) currently
has ifdefs that seperate out x86 and powerpc, so we can add an
ifdef for arm in the near future when needed.
No, I was noticing that the change you are making in this patch,
while it indeed fixes a build failure, it is a code path which does
not get executed on Arm at all.
So what effectively happens is a single assembly instruction gets
replaced with a function call on all integrated GPUs up to and
including Tigerlake.
That was the slightly annoying part I was referring to and asking
whether it was discussed before.
Sadly I don't think there is a super nice solution apart from
duplicating drm_clflush_virt_range as for example i915_clflush_range
and having it static inline. That would allow the integrated GPU
code path to remain of the same performance profile, while solving
the Arm problem. However it would be code duplication so might be
frowned upon.
I'd be tempted to go that route but it is something which needs a
bit of discussion if that hasn't happened already.
Regards,
Tvrtko
On 2022-01-31 6:55 a.m., Tvrtko Ursulin wrote:
On 28/01/2022 22:10, Michael Cheng wrote:
Use drm_clflush_virt_range instead of clflushopt and remove the
memory
barrier, since drm_clflush_virt_range takes care of that.
Signed-off-by: Michael Cheng
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 498b458fd784..0854276ff7ba 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -1332,10 +1332,8 @@ static void *reloc_vaddr(struct i915_vma
*vma,
static void clflush_write32(u32 *addr, u32 value, unsigned int
flushes)
{
if (unlikely(flushes & (CLFLUSH_BEFORE | CLFLUSH_AFTER))) {
- if (flushes & CLFLUSH_BEFORE) {
- clflushopt(addr);
- mb();
- }
+ if (flushes & CLFLUSH_BEFORE)
+ drm_clflush_virt_range(addr, sizeof(addr));
*addr = value;
@@ -1347,7 +1345,7 @@ static void clflush_write32(u32 *addr,
u32 value, unsigned int flushes)
* to ensure ordering of clflush wrt to the system.
*/
if (flushes & CLFLUSH_AFTER)
- clflushopt(addr);
+ drm_clflush_virt_range(addr, sizeof(addr));
} else
*addr = value;
}
Slightly annoying thing here (maybe in some other patches from the
series as well) is that the change adds a function call to x86
only code path, because relocations are not supported on discrete
as per:
static in
eb_validate_vma(...)
/* Relocations are disallowed for all platforms after
TGL-LP. This
* also covers all platforms with local memory.
*/
if (entry->relocation_count &&
GRAPHICS_VER(eb->i915) >= 12 && !IS_TIGERLAKE(eb->i915))
return -EINVAL;
How acceptable would be, for the whole series, to introduce a
static inline i915 cluflush wrapper and so be able to avoid
functions calls on x86? Is this something that has been discussed
and discounted already?
Regards,
Tvrtko
P.S. Hmm I am now reminded of my really old per platform build
patches. With them you would be able to compile out large portions
of the driver when building for ARM. Probably like a 3rd if my
memory serves me right.
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Fix vma lifetime (rev2)
== Series Details == Series: drm/i915: Fix vma lifetime (rev2) URL : https://patchwork.freedesktop.org/series/99618/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
Re: [Intel-gfx] [PATCH v3 1/3] drm: Stop spamming log with drm_cache message
On Tue, Feb 01, 2022 at 09:41:33AM -0800, Lucas De Marchi wrote: > On Tue, Feb 01, 2022 at 09:12:05AM -0800, Jose Souza wrote: > > On Mon, 2022-01-31 at 08:59 -0800, Lucas De Marchi wrote: > > > Only x86 and in some cases PPC have support added in drm_cache.c for the > > > clflush class of functions. However warning once is sufficient to taint > > > the log instead of spamming it with "Architecture has no drm_cache.c > > > support" every few millisecond. Switch to WARN_ONCE() so we still get > > > the log message, but only once, together with the warning. E.g: > > > > > > [ cut here ] > > > Architecture has no drm_cache.c support > > > WARNING: CPU: 80 PID: 888 at drivers/gpu/drm/drm_cache.c:139 > > > drm_clflush_sg+0x40/0x50 [drm] > > > ... > > > > > > v2 (Jani): use WARN_ONCE() and keep the message previously on pr_err() > > > > Reviewed-by: José Roberto de Souza > > > > But while at it, why not add a drm_device parameter to this function so we > > can use drm_WARN_ONCE()? > > Anyways, it is better than before. > > I thought about that, but it didn't seem justifiable because: > > 1) drm_WARN_ONCE will basically add dev_driver_string() to the log. > However the warning message here is basically helping the bootstrap of > additional archs. They shouldn't be seen on anything properly supported. > > 2) This seems all to be a layer below drm anyway and could even be used > in places outside easy access to a drm pointer. > > So, it seems the benefit of using the subsystem-specific drm_WARN_ONCE > doesn't justify the hassle of changing the callers, possibly adding > additional back pointers to have access to the drm device pointer. Initially I had same feeling as Jose, but good points raised here. Acked-by: Rodrigo Vivi > > thanks > Lucas De Marchi
[Intel-gfx] [PATCH] drm/i915: opportunistically apply ALLOC_CONTIGIOUS
It looks like this code was accidentally dropped at some point(in a slightly different form), so add it back. The gist is that if we know the allocation will be one single chunk, then we can just annotate the BO with I915_BO_ALLOC_CONTIGUOUS, even if the user doesn't bother. In the future this might prove to be potentially useful. Signed-off-by: Matthew Auld Cc: Thomas Hellström --- drivers/gpu/drm/i915/gem/i915_gem_region.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_region.c b/drivers/gpu/drm/i915/gem/i915_gem_region.c index a4350227e9ae..dd414a2bcb06 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_region.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_region.c @@ -57,6 +57,9 @@ i915_gem_object_create_region(struct intel_memory_region *mem, size = round_up(size, default_page_size); + if (default_page_size == size) + flags |= I915_BO_ALLOC_CONTIGUOUS; + GEM_BUG_ON(!size); GEM_BUG_ON(!IS_ALIGNED(size, I915_GTT_MIN_ALIGNMENT)); -- 2.34.1
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Fix vma lifetime (rev2)
== Series Details == Series: drm/i915: Fix vma lifetime (rev2) URL : https://patchwork.freedesktop.org/series/99618/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11178 -> Patchwork_22159 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_22159 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_22159, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22159/index.html Participating hosts (44 -> 42) -- Additional (1): fi-tgl-1115g4 Missing(3): fi-bxt-dsi fi-bsw-cyan fi-pnv-d510 Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_22159: ### IGT changes ### Possible regressions * igt@i915_selftest@live@workarounds: - fi-rkl-guc: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11178/fi-rkl-guc/igt@i915_selftest@l...@workarounds.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22159/fi-rkl-guc/igt@i915_selftest@l...@workarounds.html Known issues Here are the changes found in Patchwork_22159 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_basic@query-info: - fi-tgl-1115g4: NOTRUN -> [SKIP][3] ([fdo#109315]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22159/fi-tgl-1115g4/igt@amdgpu/amd_ba...@query-info.html * igt@amdgpu/amd_cs_nop@nop-gfx0: - fi-tgl-1115g4: NOTRUN -> [SKIP][4] ([fdo#109315] / [i915#2575]) +16 similar issues [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22159/fi-tgl-1115g4/igt@amdgpu/amd_cs_...@nop-gfx0.html * igt@gem_huc_copy@huc-copy: - fi-skl-6600u: NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#2190]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22159/fi-skl-6600u/igt@gem_huc_c...@huc-copy.html - fi-tgl-1115g4: NOTRUN -> [SKIP][6] ([i915#2190]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22159/fi-tgl-1115g4/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@verify-random: - fi-skl-6600u: NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#4613]) +3 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22159/fi-skl-6600u/igt@gem_lmem_swapp...@verify-random.html - fi-tgl-1115g4: NOTRUN -> [SKIP][8] ([i915#4613]) +3 similar issues [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22159/fi-tgl-1115g4/igt@gem_lmem_swapp...@verify-random.html * igt@i915_pm_backlight@basic-brightness: - fi-tgl-1115g4: NOTRUN -> [SKIP][9] ([i915#1155]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22159/fi-tgl-1115g4/igt@i915_pm_backli...@basic-brightness.html * igt@i915_selftest@live: - fi-skl-6600u: NOTRUN -> [FAIL][10] ([i915#4547]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22159/fi-skl-6600u/igt@i915_selft...@live.html * igt@i915_selftest@live@hangcheck: - fi-ivb-3770:[PASS][11] -> [INCOMPLETE][12] ([i915#3303]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11178/fi-ivb-3770/igt@i915_selftest@l...@hangcheck.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22159/fi-ivb-3770/igt@i915_selftest@l...@hangcheck.html * igt@kms_chamelium@common-hpd-after-suspend: - fi-tgl-1115g4: NOTRUN -> [SKIP][13] ([fdo#111827]) +8 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22159/fi-tgl-1115g4/igt@kms_chamel...@common-hpd-after-suspend.html * igt@kms_chamelium@vga-edid-read: - fi-skl-6600u: NOTRUN -> [SKIP][14] ([fdo#109271] / [fdo#111827]) +8 similar issues [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22159/fi-skl-6600u/igt@kms_chamel...@vga-edid-read.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic: - fi-tgl-1115g4: NOTRUN -> [SKIP][15] ([i915#4103]) +1 similar issue [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22159/fi-tgl-1115g4/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy: - fi-skl-6600u: NOTRUN -> [SKIP][16] ([fdo#109271]) +3 similar issues [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22159/fi-skl-6600u/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html * igt@kms_force_connector_basic@force-load-detect: - fi-tgl-1115g4: NOTRUN -> [SKIP][17] ([fdo#109285]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22159/fi-tgl-1115g4/igt@kms_force_connector_ba...@force-load-detect.html * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d: - fi-skl-660
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Disable unused power wells left enabled by BIOS (rev2)
== Series Details == Series: drm/i915: Disable unused power wells left enabled by BIOS (rev2) URL : https://patchwork.freedesktop.org/series/99615/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Disable unused power wells left enabled by BIOS (rev2)
== Series Details ==
Series: drm/i915: Disable unused power wells left enabled by BIOS (rev2)
URL : https://patchwork.freedesktop.org/series/99615/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11180 -> Patchwork_22160
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22160/index.html
Participating hosts (47 -> 44)
--
Additional (1): fi-icl-u2
Missing(4): fi-bsw-cyan shard-tglu fi-bdw-samus fi-pnv-d510
Known issues
Here are the changes found in Patchwork_22160 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_cs_nop@fork-gfx0:
- fi-icl-u2: NOTRUN -> [SKIP][1] ([fdo#109315]) +17 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22160/fi-icl-u2/igt@amdgpu/amd_cs_...@fork-gfx0.html
* igt@gem_huc_copy@huc-copy:
- fi-icl-u2: NOTRUN -> [SKIP][2] ([i915#2190])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22160/fi-icl-u2/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@parallel-random-engines:
- fi-icl-u2: NOTRUN -> [SKIP][3] ([i915#4613]) +3 similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22160/fi-icl-u2/igt@gem_lmem_swapp...@parallel-random-engines.html
* igt@i915_selftest@live@hangcheck:
- fi-snb-2600:[PASS][4] -> [INCOMPLETE][5] ([i915#3921])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11180/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22160/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-icl-u2: NOTRUN -> [SKIP][6] ([fdo#111827]) +8 similar issues
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22160/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-icl-u2: NOTRUN -> [SKIP][7] ([fdo#109278]) +2 similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22160/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
* igt@kms_force_connector_basic@force-load-detect:
- fi-icl-u2: NOTRUN -> [SKIP][8] ([fdo#109285])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22160/fi-icl-u2/igt@kms_force_connector_ba...@force-load-detect.html
* igt@kms_frontbuffer_tracking@basic:
- fi-cml-u2: [PASS][9] -> [DMESG-WARN][10] ([i915#4269])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11180/fi-cml-u2/igt@kms_frontbuffer_track...@basic.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22160/fi-cml-u2/igt@kms_frontbuffer_track...@basic.html
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-bdw-5557u: [PASS][11] -> [INCOMPLETE][12] ([i915#146] /
[i915#])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11180/fi-bdw-5557u/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22160/fi-bdw-5557u/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
* igt@prime_vgem@basic-userptr:
- fi-icl-u2: NOTRUN -> [SKIP][13] ([i915#3301])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22160/fi-icl-u2/igt@prime_v...@basic-userptr.html
Warnings
* igt@i915_selftest@live@hangcheck:
- bat-dg1-6: [DMESG-FAIL][14] ([i915#4957]) -> [DMESG-FAIL][15]
([i915#4494] / [i915#4957])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11180/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22160/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
[fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
[fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#146]: https://gitlab.freedesktop.org/drm/intel/issues/146
[i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
[i915#2582]: https://gitlab.freedesktop.org/drm/intel/issues/2582
[i915#3301]: https://gitlab.freedesktop.org/drm/intel/issues/3301
[i915#3921]: https://gitlab.freedesktop.org/drm/intel/issues/3921
[i915#4269]: https://gitlab.freedesktop.org/drm/intel/issues/4269
[i915#]: https://gitlab.freedesktop.org/drm/intel/issues/
[i915#4494]: https://gitlab.freedesktop.org/drm/intel/issues/4494
[i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
[i915#4898]: https://gitlab.freedesktop.org/drm/intel/issues/4898
[i915#4957]: https://git
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: opportunistically apply ALLOC_CONTIGIOUS
== Series Details == Series: drm/i915: opportunistically apply ALLOC_CONTIGIOUS URL : https://patchwork.freedesktop.org/series/99631/ State : success == Summary == CI Bug Log - changes from CI_DRM_11180 -> Patchwork_22161 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22161/index.html Participating hosts (47 -> 45) -- Additional (1): fi-icl-u2 Missing(3): fi-bsw-cyan shard-tglu fi-bdw-samus Known issues Here are the changes found in Patchwork_22161 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_cs_nop@fork-gfx0: - fi-icl-u2: NOTRUN -> [SKIP][1] ([fdo#109315]) +17 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22161/fi-icl-u2/igt@amdgpu/amd_cs_...@fork-gfx0.html * igt@gem_exec_suspend@basic-s3@smem: - fi-bdw-5557u: [PASS][2] -> [INCOMPLETE][3] ([i915#146]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11180/fi-bdw-5557u/igt@gem_exec_suspend@basic...@smem.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22161/fi-bdw-5557u/igt@gem_exec_suspend@basic...@smem.html * igt@gem_huc_copy@huc-copy: - fi-icl-u2: NOTRUN -> [SKIP][4] ([i915#2190]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22161/fi-icl-u2/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@parallel-random-engines: - fi-icl-u2: NOTRUN -> [SKIP][5] ([i915#4613]) +3 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22161/fi-icl-u2/igt@gem_lmem_swapp...@parallel-random-engines.html * igt@i915_pm_rpm@module-reload: - fi-cfl-8109u: [PASS][6] -> [DMESG-WARN][7] ([i915#203] / [i915#295]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11180/fi-cfl-8109u/igt@i915_pm_...@module-reload.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22161/fi-cfl-8109u/igt@i915_pm_...@module-reload.html * igt@i915_selftest@live: - fi-skl-6600u: NOTRUN -> [FAIL][8] ([i915#4547]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22161/fi-skl-6600u/igt@i915_selft...@live.html * igt@i915_selftest@live@hangcheck: - fi-hsw-4770:[PASS][9] -> [INCOMPLETE][10] ([i915#3303]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11180/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22161/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html - fi-snb-2600:[PASS][11] -> [INCOMPLETE][12] ([i915#3921]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11180/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22161/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html * igt@i915_selftest@live@memory_region: - fi-cfl-8109u: [PASS][13] -> [DMESG-WARN][14] ([i915#203]) +34 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11180/fi-cfl-8109u/igt@i915_selftest@live@memory_region.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22161/fi-cfl-8109u/igt@i915_selftest@live@memory_region.html * igt@kms_chamelium@hdmi-hpd-fast: - fi-icl-u2: NOTRUN -> [SKIP][15] ([fdo#111827]) +8 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22161/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic: - fi-icl-u2: NOTRUN -> [SKIP][16] ([fdo#109278]) +2 similar issues [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22161/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html * igt@kms_force_connector_basic@force-load-detect: - fi-icl-u2: NOTRUN -> [SKIP][17] ([fdo#109285]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22161/fi-icl-u2/igt@kms_force_connector_ba...@force-load-detect.html * igt@kms_frontbuffer_tracking@basic: - fi-cml-u2: [PASS][18] -> [DMESG-WARN][19] ([i915#4269]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11180/fi-cml-u2/igt@kms_frontbuffer_track...@basic.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22161/fi-cml-u2/igt@kms_frontbuffer_track...@basic.html * igt@kms_pipe_crc_basic@read-crc-pipe-b: - fi-cfl-8109u: [PASS][20] -> [DMESG-WARN][21] ([i915#295]) +11 similar issues [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11180/fi-cfl-8109u/igt@kms_pipe_crc_ba...@read-crc-pipe-b.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22161/fi-cfl-8109u/igt@kms_pipe_crc_ba...@read-crc-pipe-b.html * igt@prime_vgem@basic-userptr: - fi-skl-6600u: NOTRUN -> [SKIP][22] ([fdo#109271]) [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22161/fi-skl-6600u/igt@prime_v...@basic-userptr.htm
Re: [Intel-gfx] [PATCH 1/6] drm: add writeback pointers to drm_connector
Hi Kandpal,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm/drm-next]
[also build test ERROR on drm-intel/for-linux-next drm-tip/drm-tip v5.17-rc2
next-20220202]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Kandpal-Suraj/drm-writeback-connector-changes/20220202-164832
base: git://anongit.freedesktop.org/drm/drm drm-next
config: i386-randconfig-a013-20220131
(https://download.01.org/0day-ci/archive/20220203/202202030437.kmrdd39e-...@intel.com/config)
compiler: clang version 14.0.0 (https://github.com/llvm/llvm-project
6b1e844b69f15bb7dffaf9365cd2b355d2eb7579)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://github.com/0day-ci/linux/commit/57ad56d769873f62f87fe432243030ceb1678f87
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Kandpal-Suraj/drm-writeback-connector-changes/20220202-164832
git checkout 57ad56d769873f62f87fe432243030ceb1678f87
# save the config file to linux build tree
mkdir build_dir
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1
O=build_dir ARCH=i386 SHELL=/bin/bash
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
Note: the
linux-review/Kandpal-Suraj/drm-writeback-connector-changes/20220202-164832 HEAD
75bbd0a8b1fb58f702279bfbc2fe2d74db8f7028 builds fine.
It only hurts bisectability.
All errors (new ones prefixed by >>):
>> drivers/gpu/drm/vkms/vkms_writeback.c:117:56: error: member reference type
>> 'struct drm_connector *' is a pointer; did you mean to use '->'?
struct drm_connector_state *conn_state = wb_conn->base.state;
~^
->
>> drivers/gpu/drm/vkms/vkms_writeback.c:143:38: error: member reference type
>> 'struct drm_encoder *' is a pointer; did you mean to use '->'?
vkmsdev->output.wb_connector.encoder.possible_crtcs = 1;
^
->
>> drivers/gpu/drm/vkms/vkms_writeback.c:144:27: error: incompatible pointer
>> types passing 'struct drm_connector **' to parameter of type 'struct
>> drm_connector *'; remove & [-Werror,-Wincompatible-pointer-types]
drm_connector_helper_add(&wb->base, &vkms_wb_conn_helper_funcs);
^
include/drm/drm_modeset_helper_vtables.h:1153:67: note: passing argument to
parameter 'connector' here
static inline void drm_connector_helper_add(struct drm_connector *connector,
^
3 errors generated.
vim +117 drivers/gpu/drm/vkms/vkms_writeback.c
dbd9d80c1b2e03 Rodrigo Siqueira 2020-08-30 108
dbd9d80c1b2e03 Rodrigo Siqueira 2020-08-30 109 static void
vkms_wb_atomic_commit(struct drm_connector *conn,
eca22edb37d29f Maxime Ripard2020-11-18 110
struct drm_atomic_state *state)
dbd9d80c1b2e03 Rodrigo Siqueira 2020-08-30 111 {
eca22edb37d29f Maxime Ripard2020-11-18 112 struct
drm_connector_state *connector_state = drm_atomic_get_new_connector_state(state,
eca22edb37d29f Maxime Ripard2020-11-18 113
conn);
dbd9d80c1b2e03 Rodrigo Siqueira 2020-08-30 114 struct vkms_device
*vkmsdev = drm_device_to_vkms_device(conn->dev);
dbd9d80c1b2e03 Rodrigo Siqueira 2020-08-30 115 struct vkms_output
*output = &vkmsdev->output;
dbd9d80c1b2e03 Rodrigo Siqueira 2020-08-30 116 struct
drm_writeback_connector *wb_conn = &output->wb_connector;
dbd9d80c1b2e03 Rodrigo Siqueira 2020-08-30 @117 struct
drm_connector_state *conn_state = wb_conn->base.state;
dbd9d80c1b2e03 Rodrigo Siqueira 2020-08-30 118 struct vkms_crtc_state
*crtc_state = output->composer_state;
dbd9d80c1b2e03 Rodrigo Siqueira 2020-08-30 119
dbd9d80c1b2e03 Rodrigo Siqueira 2020-08-30 120 if (!conn_state)
dbd9d80c1b2e03 Rodrigo Siqueira 2020-08-30 121 return;
dbd9d80c1b2e03 Rodrigo Siqueira 2020-08-30 122
dbd9d80c1b2e03 Rodrigo Siqueira 2020-08-30 123
vkms_set_composer(&vkmsdev->output, true);
dbd9d80c1b2e03 Rodrigo Siqueira 2020-08-30 124
dbd9d80c1b2e03 Rodrigo Siqueira 2020-08-30 125
spin_loc
Re: [Intel-gfx] [PATCH] drm/i915: Flip guc_id allocation partition
On 13.01.2022 17:27, Matthew Brost wrote:
> Move the multi-lrc guc_id from the lower allocation partition (0 to
> number of multi-lrc guc_ids) to upper allocation partition (number of
> single-lrc to max guc_ids).
>
> This will help when a native driver transitions to a PF after driver
> load time. If the perma-pin guc_ids (kernel contexts) are in a low range
> it is easy reduce total number of guc_ids as the allocated slrc are in a
> valid range the mlrc range moves to an unused range. Assuming no mlrc
> are allocated and few slrc are used the native to PF transition is
> seamless for the guc_id resource.
>
> v2:
> (Michal / Tvrtko)
> - Add an explaination to commit message of why this patch is needed
> (Michal / Piotr)
> - Replace marcos with functions
> (Michal)
> - Rework logic flow in new_mlrc_guc_id
> - Unconditionally call bitmap_free
> v3:
> (Michal)
> - Move allocation of mlrc bitmap back submission init
> (CI)
> - Resend for CI
>
> Signed-off-by: Matthew Brost
> ---
> .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 77 ++-
> 1 file changed, 56 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> index 23a40f10d376d..fce58365b3ff8 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> @@ -138,17 +138,6 @@ guc_create_parallel(struct intel_engine_cs **engines,
>
> #define GUC_REQUEST_SIZE 64 /* bytes */
>
> -/*
> - * We reserve 1/16 of the guc_ids for multi-lrc as these need to be
> contiguous
> - * per the GuC submission interface. A different allocation algorithm is used
> - * (bitmap vs. ida) between multi-lrc and single-lrc hence the reason to
> - * partition the guc_id space. We believe the number of multi-lrc contexts in
> - * use should be low and 1/16 should be sufficient. Minimum of 32 guc_ids for
> - * multi-lrc.
> - */
> -#define NUMBER_MULTI_LRC_GUC_ID(guc) \
> - ((guc)->submission_state.num_guc_ids / 16)
> -
> /*
> * Below is a set of functions which control the GuC scheduling state which
> * require a lock.
> @@ -1746,6 +1735,7 @@ void intel_guc_submission_reset_finish(struct intel_guc
> *guc)
> }
>
> static void destroyed_worker_func(struct work_struct *w);
> +static int number_mlrc_guc_id(struct intel_guc *guc);
>
> /*
> * Set up the memory resources to be shared with the GuC (via the GGTT)
> @@ -1778,7 +1768,7 @@ int intel_guc_submission_init(struct intel_guc *guc)
> destroyed_worker_func);
>
> guc->submission_state.guc_ids_bitmap =
> - bitmap_zalloc(NUMBER_MULTI_LRC_GUC_ID(guc), GFP_KERNEL);
> + bitmap_zalloc(number_mlrc_guc_id(guc), GFP_KERNEL);
to fully benefit from the id partition flip we likely will have to
allocate bitmap 'just-in-time' when first mlrc id is needed
so something like you had in early rev but abandon to avoid alloc inside
spinlock - but I'm wondering why we can't alloc bitmap for mlrc case,
while we allow allocation for slrc (as ida_simple_get may alloc, no?
> if (!guc->submission_state.guc_ids_bitmap)
> return -ENOMEM;
>
> @@ -1864,6 +1854,57 @@ static void guc_submit_request(struct i915_request *rq)
> spin_unlock_irqrestore(&sched_engine->lock, flags);
> }
>
> +/*
> + * We reserve 1/16 of the guc_ids for multi-lrc as these need to be
> contiguous
> + * per the GuC submission interface. A different allocation algorithm is used
> + * (bitmap vs. ida) between multi-lrc and single-lrc hence the reason to
> + * partition the guc_id space. We believe the number of multi-lrc contexts in
> + * use should be low and 1/16 should be sufficient.
do we have any other numbers as guideline ?
while it is easy assumption that 1/16 from 64K contexts may be
sufficient, what about 1/16 of 1K contexts ? will that work too ?
also, do we have to make hard split ? what if there will be no users for
mlrc but more slrc contexts would be beneficial ? or the opposite ?
> + */
> +#define MLRC_GUC_ID_RATIO16
> +
> +static int number_mlrc_guc_id(struct intel_guc *guc)
> +{
> + return guc->submission_state.num_guc_ids / MLRC_GUC_ID_RATIO;
> +}
> +
> +static int number_slrc_guc_id(struct intel_guc *guc)
> +{
> + return guc->submission_state.num_guc_ids - number_mlrc_guc_id(guc);
> +}
> +
> +static int mlrc_guc_id_base(struct intel_guc *guc)
> +{
> + return number_slrc_guc_id(guc);
> +}
> +
> +static int new_mlrc_guc_id(struct intel_guc *guc, struct intel_context *ce)
> +{
> + int ret;
> +
> + GEM_BUG_ON(!intel_context_is_parent(ce));
> + GEM_BUG_ON(!guc->submission_state.guc_ids_bitmap);
> +
> + ret = bitmap_find_free_region(guc->submission_state.guc_ids_bitmap,
> +number_mlrc_guc_id(guc),
> +order_base_2(ce->parallel.number_children
> +
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Disable unused power wells left enabled by BIOS (rev2)
== Series Details == Series: drm/i915: Disable unused power wells left enabled by BIOS (rev2) URL : https://patchwork.freedesktop.org/series/99615/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11180_full -> Patchwork_22160_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_22160_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_22160_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Participating hosts (11 -> 11) -- No changes in participating hosts Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_22160_full: ### IGT changes ### Possible regressions * igt@i915_pm_rpm@system-suspend-devices: - shard-iclb: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11180/shard-iclb6/igt@i915_pm_...@system-suspend-devices.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22160/shard-iclb7/igt@i915_pm_...@system-suspend-devices.html Known issues Here are the changes found in Patchwork_22160_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_sseu@invalid-args: - shard-tglb: NOTRUN -> [SKIP][3] ([i915#280]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22160/shard-tglb1/igt@gem_ctx_s...@invalid-args.html * igt@gem_exec_balancer@parallel: - shard-iclb: [PASS][4] -> [SKIP][5] ([i915#4525]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11180/shard-iclb1/igt@gem_exec_balan...@parallel.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22160/shard-iclb8/igt@gem_exec_balan...@parallel.html * igt@gem_exec_fair@basic-flow@rcs0: - shard-skl: NOTRUN -> [SKIP][6] ([fdo#109271]) +291 similar issues [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22160/shard-skl8/igt@gem_exec_fair@basic-f...@rcs0.html * igt@gem_exec_fair@basic-none-rrul@rcs0: - shard-glk: [PASS][7] -> [FAIL][8] ([i915#2842]) +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11180/shard-glk5/igt@gem_exec_fair@basic-none-r...@rcs0.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22160/shard-glk2/igt@gem_exec_fair@basic-none-r...@rcs0.html - shard-tglb: NOTRUN -> [FAIL][9] ([i915#2842]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22160/shard-tglb1/igt@gem_exec_fair@basic-none-r...@rcs0.html * igt@gem_exec_fair@basic-pace-solo@rcs0: - shard-kbl: [PASS][10] -> [FAIL][11] ([i915#2842]) +1 similar issue [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11180/shard-kbl7/igt@gem_exec_fair@basic-pace-s...@rcs0.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22160/shard-kbl6/igt@gem_exec_fair@basic-pace-s...@rcs0.html * igt@gem_exec_fair@basic-pace@bcs0: - shard-tglb: [PASS][12] -> [FAIL][13] ([i915#2842]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11180/shard-tglb1/igt@gem_exec_fair@basic-p...@bcs0.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22160/shard-tglb1/igt@gem_exec_fair@basic-p...@bcs0.html * igt@gem_exec_fair@basic-throttle@rcs0: - shard-iclb: [PASS][14] -> [FAIL][15] ([i915#2849]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11180/shard-iclb5/igt@gem_exec_fair@basic-throt...@rcs0.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22160/shard-iclb8/igt@gem_exec_fair@basic-throt...@rcs0.html * igt@gem_huc_copy@huc-copy: - shard-skl: NOTRUN -> [SKIP][16] ([fdo#109271] / [i915#2190]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22160/shard-skl6/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@heavy-random: - shard-iclb: NOTRUN -> [SKIP][17] ([i915#4613]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22160/shard-iclb3/igt@gem_lmem_swapp...@heavy-random.html * igt@gem_lmem_swapping@parallel-random: - shard-skl: NOTRUN -> [SKIP][18] ([fdo#109271] / [i915#4613]) +3 similar issues [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22160/shard-skl8/igt@gem_lmem_swapp...@parallel-random.html * igt@gem_lmem_swapping@verify-random: - shard-apl: NOTRUN -> [SKIP][19] ([fdo#109271] / [i915#4613]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22160/shard-apl8/igt@gem_lmem_swapp...@verify-random.html * igt@gem_mmap_wc@bad-offset: - shard-skl: NOTRUN -> [DMESG-WARN][20] ([i915#1982]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22160/shard-skl6/igt@gem_mmap...@bad-offset.html * igt@gem_pxp@fail-inv
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: opportunistically apply ALLOC_CONTIGIOUS
== Series Details == Series: drm/i915: opportunistically apply ALLOC_CONTIGIOUS URL : https://patchwork.freedesktop.org/series/99631/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11180_full -> Patchwork_22161_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_22161_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_22161_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Participating hosts (11 -> 11) -- No changes in participating hosts Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_22161_full: ### IGT changes ### Possible regressions * igt@gem_ctx_persistence@smoketest: - shard-tglb: [PASS][1] -> [FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11180/shard-tglb6/igt@gem_ctx_persiste...@smoketest.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22161/shard-tglb8/igt@gem_ctx_persiste...@smoketest.html * igt@gem_exec_reloc@basic-concurrent16: - shard-snb: [PASS][3] -> [INCOMPLETE][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11180/shard-snb5/igt@gem_exec_re...@basic-concurrent16.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22161/shard-snb6/igt@gem_exec_re...@basic-concurrent16.html Known issues Here are the changes found in Patchwork_22161_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@preservation-s3@vecs0: - shard-apl: [PASS][5] -> [DMESG-WARN][6] ([i915#180]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11180/shard-apl8/igt@gem_ctx_isolation@preservation...@vecs0.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22161/shard-apl4/igt@gem_ctx_isolation@preservation...@vecs0.html * igt@gem_ctx_sseu@invalid-args: - shard-tglb: NOTRUN -> [SKIP][7] ([i915#280]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22161/shard-tglb7/igt@gem_ctx_s...@invalid-args.html * igt@gem_eio@in-flight-contexts-immediate: - shard-tglb: [PASS][8] -> [TIMEOUT][9] ([i915#3063]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11180/shard-tglb7/igt@gem_...@in-flight-contexts-immediate.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22161/shard-tglb6/igt@gem_...@in-flight-contexts-immediate.html * igt@gem_eio@unwedge-stress: - shard-iclb: [PASS][10] -> [TIMEOUT][11] ([i915#2481] / [i915#3070]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11180/shard-iclb4/igt@gem_...@unwedge-stress.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22161/shard-iclb4/igt@gem_...@unwedge-stress.html * igt@gem_exec_fair@basic-flow@rcs0: - shard-skl: NOTRUN -> [SKIP][12] ([fdo#109271]) +186 similar issues [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22161/shard-skl4/igt@gem_exec_fair@basic-f...@rcs0.html * igt@gem_exec_fair@basic-none-rrul@rcs0: - shard-glk: [PASS][13] -> [FAIL][14] ([i915#2842]) +1 similar issue [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11180/shard-glk5/igt@gem_exec_fair@basic-none-r...@rcs0.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22161/shard-glk8/igt@gem_exec_fair@basic-none-r...@rcs0.html - shard-tglb: NOTRUN -> [FAIL][15] ([i915#2842]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22161/shard-tglb7/igt@gem_exec_fair@basic-none-r...@rcs0.html * igt@gem_exec_fair@basic-none@vcs1: - shard-iclb: NOTRUN -> [FAIL][16] ([i915#2842]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22161/shard-iclb2/igt@gem_exec_fair@basic-n...@vcs1.html * igt@gem_exec_fair@basic-pace-solo@rcs0: - shard-kbl: [PASS][17] -> [FAIL][18] ([i915#2842]) +1 similar issue [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11180/shard-kbl7/igt@gem_exec_fair@basic-pace-s...@rcs0.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22161/shard-kbl6/igt@gem_exec_fair@basic-pace-s...@rcs0.html * igt@gem_exec_fair@basic-pace@bcs0: - shard-tglb: [PASS][19] -> [FAIL][20] ([i915#2842]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11180/shard-tglb1/igt@gem_exec_fair@basic-p...@bcs0.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22161/shard-tglb1/igt@gem_exec_fair@basic-p...@bcs0.html * igt@gem_exec_fair@basic-throttle@rcs0: - shard-iclb: [PASS][21] -> [FAIL][22] ([i915#2849]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11180/shard-iclb5/igt@gem_exec_fair@basic-throt...@rcs0.html [22]: https://intel-gfx
[Intel-gfx] linux-next: manual merge of the drm-intel tree with the drm-intel-fixes tree
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in:
drivers/gpu/drm/i915/i915_reg.h
between commit:
b3f74938d656 ("drm/i915/pmu: Use PM timestamp instead of RING TIMESTAMP for
reference")
from the drm-intel-fixes tree and commit:
22ba60f617bd ("drm/i915: Move [more] GT registers to their own header file")
from the drm-intel tree.
I fixed it up (I just used the latter version) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging. You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.
--
Cheers,
Stephen Rothwell
pgpuwArqosfza.pgp
Description: OpenPGP digital signature
[Intel-gfx] linux-next: manual merge of the drm-intel-gt tree with the drm-intel tree
Hi all,
Today's linux-next merge of the drm-intel-gt tree got a conflict in:
drivers/gpu/drm/i915/i915_reg.h
between commit:
0d6419e9c855 ("drm/i915: Move GT registers to their own header file")
from the drm-intel tree and commit:
270677026261 ("drm/i915/dg2: Add Wa_14015227452")
from the drm-intel-gt tree.
I fixed it up (I used the former version and then added the following
merge fix patch) and can carry the fix as necessary. This is now fixed
as far as linux-next is concerned, but any non trivial conflicts should
be mentioned to your upstream maintainer when your tree is submitted for
merging. You may also want to consider cooperating with the maintainer
of the conflicting tree to minimise any particularly complex conflicts.
It would be nice if you synced up these 2 trees (by merging one into
the other) as I am carrying several merge fix patches due to the
splitting up of i915_reg.h.
From: Stephen Rothwell
Date: Thu, 3 Feb 2022 11:09:02 +1100
Subject: [PATCH] fix up for "drm/i915: Move GT registers to their own header
file"
Signed-off-by: Stephen Rothwell
---
drivers/gpu/drm/i915/gt/intel_gt_regs.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index 16d98ebee687..a6f0220c2e9f 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -1482,6 +1482,7 @@ enum {
#define GEN9_ROW_CHICKEN4 _MMIO(0xe48c)
#define GEN12_DISABLE_GRF_CLEAR REG_BIT(13)
+#define XEHP_DIS_BBL_SYSPIPE REG_BIT(11)
#define GEN12_DISABLE_TDL_PUSH REG_BIT(9)
#define GEN11_DIS_PICK_2ND_EUREG_BIT(7)
#define GEN12_DISABLE_HDR_PAST_PAYLOAD_HOLD_FIX REG_BIT(4)
--
2.34.1
--
Cheers,
Stephen Rothwell
pgpDpgHxJXy24.pgp
Description: OpenPGP digital signature
[Intel-gfx] ✗ Fi.CI.BAT: failure for linux-next: manual merge of the drm-intel-gt tree with the drm-intel tree (rev2)
== Series Details == Series: linux-next: manual merge of the drm-intel-gt tree with the drm-intel tree (rev2) URL : https://patchwork.freedesktop.org/series/99294/ State : failure == Summary == Applying: linux-next: manual merge of the drm-intel-gt tree with the drm-intel tree Using index info to reconstruct a base tree... M drivers/gpu/drm/i915/gt/intel_gt_regs.h Falling back to patching base and 3-way merge... No changes -- Patch already applied.
Re: [Intel-gfx] [PATCH 13/20] drm/i915/ttm: mappable migration on fault
On 1/26/22 16:21, Matthew Auld wrote:
The end goal is to have userspace tell the kernel what buffers will
require CPU access, however if we ever reach the CPU fault handler, and
the current resource is not mappable, then we should attempt to migrate
the buffer to the mappable portion of LMEM, or even system memory, if the
allowable placements permit it.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 58 ++---
1 file changed, 52 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index 8376e4c3d290..7299053fb1ec 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -636,11 +636,25 @@ static void i915_ttm_swap_notify(struct ttm_buffer_object
*bo)
i915_ttm_purge(obj);
}
+static bool i915_ttm_resource_mappable(struct ttm_resource *res)
+{
+ struct i915_ttm_buddy_resource *bman_res = to_ttm_buddy_resource(res);
+
+ if (!i915_ttm_cpu_maps_iomem(res))
+ return true;
+
+ return bman_res->used_visible_size == bman_res->base.num_pages;
+}
+
static int i915_ttm_io_mem_reserve(struct ttm_device *bdev, struct
ttm_resource *mem)
{
+
Stray line.
Otherwise LGTM.
Reviewed-by: Thomas Hellström
