Re: [PATCH v2 2/3] dt-bindings: drm/bridge: ps8640: Add aux-bus child
Quoting Philip Chen (2021-09-29 17:34:57) > dp-aux-bus.yaml says we can list an eDP panel as a child of > an eDP controller node to represent the fact that the panel > is connected to the controller's DP AUX bus. > > Let's add it to the ps8640 bindings. > > Signed-off-by: Philip Chen > --- Reviewed-by: Stephen Boyd
Re: [PATCH 2/4] amdgpu_ucode: reduce number of pr_debug calls
On Wed, Sep 29, 2021 at 8:08 PM Joe Perches wrote: > > On Wed, 2021-09-29 at 19:44 -0600, Jim Cromie wrote: > > There are blocks of DRM_DEBUG calls, consolidate their args into > > single calls. With dynamic-debug in use, each callsite consumes 56 > > bytes of callsite data, and this patch removes about 65 calls, so > > it saves ~3.5kb. > > > > no functional changes. > > No functional change, but an output logging content change. > > > RFC: this creates multi-line log messages, does that break any syslog > > conventions ? > > It does change the output as each individual DRM_DEBUG is a call to > __drm_dbg which is effectively: > > printk(KERN_DEBUG "[" DRM_NAME ":%ps] %pV", >__builtin_return_address(0), ); > > ok. that would disqualify the nouveau patch too.
Re: [PATCH v8 09/12] media: mtk-vcodec: Get rid of mtk_smi_larb_get/put
Hi Dafna,
Thanks very much for the review.
On Wed, 2021-09-29 at 14:13 +0200, Dafna Hirschfeld wrote:
>
> On 29.09.21 03:37, Yong Wu wrote:
> > MediaTek IOMMU has already added the device_link between the
> > consumer
> > and smi-larb device. If the vcodec device call the
> > pm_runtime_get_sync,
> > the smi-larb's pm_runtime_get_sync also be called automatically.
> >
> > CC: Tiffany Lin
> > CC: Irui Wang
> > Signed-off-by: Yong Wu
> > Reviewed-by: Evan Green
> > Acked-by: Tiffany Lin
> > Reviewed-by: Dafna Hirschfeld
> > ---
> > .../platform/mtk-vcodec/mtk_vcodec_dec_pm.c | 37 +++---
> > --
> > .../platform/mtk-vcodec/mtk_vcodec_drv.h | 3 --
> > .../platform/mtk-vcodec/mtk_vcodec_enc.c | 1 -
> > .../platform/mtk-vcodec/mtk_vcodec_enc_pm.c | 44 +++---
> > -
> > 4 files changed, 10 insertions(+), 75 deletions(-)
> >
> > diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c
> > b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c
> > index 6038db96f71c..d0bf9aa3b29d 100644
> > --- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c
> > +++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c
> > @@ -8,14 +8,12 @@
> > #include
> > #include
> > #include
> > -#include
> >
> > #include "mtk_vcodec_dec_pm.h"
> > #include "mtk_vcodec_util.h"
> >
> > int mtk_vcodec_init_dec_pm(struct mtk_vcodec_dev *mtkdev)
> > {
> > - struct device_node *node;
> > struct platform_device *pdev;
> > struct mtk_vcodec_pm *pm;
> > struct mtk_vcodec_clk *dec_clk;
> > @@ -26,18 +24,7 @@ int mtk_vcodec_init_dec_pm(struct mtk_vcodec_dev
> > *mtkdev)
> > pm = >pm;
> > pm->mtkdev = mtkdev;
> > dec_clk = >vdec_clk;
> > - node = of_parse_phandle(pdev->dev.of_node, "mediatek,larb", 0);
> > - if (!node) {
> > - mtk_v4l2_err("of_parse_phandle mediatek,larb fail!");
> > - return -1;
> > - }
> >
> > - pdev = of_find_device_by_node(node);
> > - of_node_put(node);
> > - if (WARN_ON(!pdev)) {
> > - return -1;
> > - }
> > - pm->larbvdec = >dev;
> > pdev = mtkdev->plat_dev;
> > pm->dev = >dev;
> >
> > @@ -47,14 +34,11 @@ int mtk_vcodec_init_dec_pm(struct
> > mtk_vcodec_dev *mtkdev)
> > dec_clk->clk_info = devm_kcalloc(>dev,
> > dec_clk->clk_num, sizeof(*clk_info),
> > GFP_KERNEL);
> > - if (!dec_clk->clk_info) {
> > - ret = -ENOMEM;
> > - goto put_device;
> > - }
> > + if (!dec_clk->clk_info)
> > + return -ENOMEM;
> > } else {
> > mtk_v4l2_err("Failed to get vdec clock count");
> > - ret = -EINVAL;
> > - goto put_device;
> > + return -EINVAL;
> > }
> >
> > for (i = 0; i < dec_clk->clk_num; i++) {
> > @@ -63,29 +47,24 @@ int mtk_vcodec_init_dec_pm(struct
> > mtk_vcodec_dev *mtkdev)
> > "clock-names", i, _info->clk_name);
> > if (ret) {
> > mtk_v4l2_err("Failed to get clock name id =
> > %d", i);
> > - goto put_device;
> > + return ret;
> > }
> > clk_info->vcodec_clk = devm_clk_get(>dev,
> > clk_info->clk_name);
> > if (IS_ERR(clk_info->vcodec_clk)) {
> > mtk_v4l2_err("devm_clk_get (%d)%s fail", i,
> > clk_info->clk_name);
> > - ret = PTR_ERR(clk_info->vcodec_clk);
> > - goto put_device;
> > + return PTR_ERR(clk_info->vcodec_clk);
> > }
> > }
> >
> > pm_runtime_enable(>dev);
> > return 0;
> > -put_device:
> > - put_device(pm->larbvdec);
> > - return ret;
> > }
> >
> > void mtk_vcodec_release_dec_pm(struct mtk_vcodec_dev *dev)
> > {
> > pm_runtime_disable(dev->pm.dev);
> > - put_device(dev->pm.larbvdec);
> > }
>
> Now that functions only do 'pm_runtime_disable(dev->pm.dev);' so it
> will be more
> readable to remove the function mtk_vcodec_release_dec_pm
> and replace with pm_runtime_disable(dev->pm.dev);
> Same for the 'enc' equivalent.
Make sense. But It may be not proper if using pm_runtime_disable
as the symmetry with mtk_vcodec_init_dec_pm in the mtk_vcodec_probe.
Maybe we should move pm_runtime_enable out from mtk_vcodec_init_dec_pm
into mtk_vcodec_probe. I could do a new patch for this. Is this ok for
you?
>
> Thanks,
> Dafna
[snip]
[PATCH v6 2/3] drm/bridge: ti-sn65dsi86: Use regmap_bulk_write API
The multi-register u16 write operation can use regmap_bulk_write()
instead of two separate regmap_write() calls.
It's uncertain if this has any effect on the actual updates of the
underlying registers, but this at least gives the hardware the
opportunity and saves us one transation on the bus.
Signed-off-by: Bjorn Andersson
---
Changes since v5:
- Extracted this hunk from patch 3.
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
index 41d48a393e7f..412fb6f564ea 100644
--- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
+++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
@@ -193,8 +193,9 @@ static const struct regmap_config
ti_sn65dsi86_regmap_config = {
static void ti_sn65dsi86_write_u16(struct ti_sn65dsi86 *pdata,
unsigned int reg, u16 val)
{
- regmap_write(pdata->regmap, reg, val & 0xFF);
- regmap_write(pdata->regmap, reg + 1, val >> 8);
+ u8 buf[2] = { val & 0xff, val >> 8 };
+
+ regmap_bulk_write(pdata->regmap, reg, buf, ARRAY_SIZE(buf));
}
static u32 ti_sn_bridge_get_dsi_freq(struct ti_sn65dsi86 *pdata)
--
2.32.0
[PATCH v6 3/3] drm/bridge: ti-sn65dsi86: Implement the pwm_chip
The SN65DSI86 provides the ability to supply a PWM signal on GPIO 4,
with the primary purpose of controlling the backlight of the attached
panel. Add an implementation that exposes this using the standard PWM
framework, to allow e.g. pwm-backlight to expose this to the user.
Signed-off-by: Bjorn Andersson
---
Changes since v5:
- Make ti_sn65dsi86_read_u16() use regmap_bulk_read()
- Update the wording related to the formula for the period being wrong to not
just say I'm "assuming because it's easier".
- Updated comment related to minimum period
- Clamp duty <= period in get_state()
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 366 +-
1 file changed, 360 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
index 412fb6f564ea..ccf6496cc9ff 100644
--- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
+++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
@@ -4,7 +4,9 @@
* datasheet: https://www.ti.com/lit/ds/symlink/sn65dsi86.pdf
*/
+#include
#include
+#include
#include
#include
#include
@@ -15,6 +17,7 @@
#include
#include
#include
+#include
#include
#include
@@ -91,6 +94,13 @@
#define SN_ML_TX_MODE_REG 0x96
#define ML_TX_MAIN_LINK_OFF 0
#define ML_TX_NORMAL_MODE BIT(0)
+#define SN_PWM_PRE_DIV_REG 0xA0
+#define SN_BACKLIGHT_SCALE_REG 0xA1
+#define BACKLIGHT_SCALE_MAX 0x
+#define SN_BACKLIGHT_REG 0xA3
+#define SN_PWM_EN_INV_REG 0xA5
+#define SN_PWM_INV_MASK BIT(0)
+#define SN_PWM_EN_MASKBIT(1)
#define SN_AUX_CMD_STATUS_REG 0xF4
#define AUX_IRQ_STATUS_AUX_RPLY_TOUT BIT(3)
#define AUX_IRQ_STATUS_AUX_SHORT BIT(5)
@@ -113,11 +123,14 @@
#define SN_LINK_TRAINING_TRIES 10
+#define SN_PWM_GPIO_IDX3 /* 4th GPIO */
+
/**
* struct ti_sn65dsi86 - Platform data for ti-sn65dsi86 driver.
* @bridge_aux: AUX-bus sub device for MIPI-to-eDP bridge functionality.
* @gpio_aux: AUX-bus sub device for GPIO controller functionality.
* @aux_aux: AUX-bus sub device for eDP AUX channel functionality.
+ * @pwm_aux: AUX-bus sub device for PWM controller functionality.
*
* @dev: Pointer to the top level (i2c) device.
* @regmap: Regmap for accessing i2c.
@@ -145,11 +158,17 @@
*bitmap so we can do atomic ops on it without an extra
*lock so concurrent users of our 4 GPIOs don't stomp on
*each other's read-modify-write.
+ *
+ * @pchip:pwm_chip if the PWM is exposed.
+ * @pwm_enabled: Used to track if the PWM signal is currently enabled.
+ * @pwm_pin_busy: Track if GPIO4 is currently requested for GPIO or PWM.
+ * @pwm_refclk_freq: Cache for the reference clock input to the PWM.
*/
struct ti_sn65dsi86 {
struct auxiliary_device bridge_aux;
struct auxiliary_device gpio_aux;
struct auxiliary_device aux_aux;
+ struct auxiliary_device pwm_aux;
struct device *dev;
struct regmap *regmap;
@@ -172,6 +191,12 @@ struct ti_sn65dsi86 {
struct gpio_chipgchip;
DECLARE_BITMAP(gchip_output, SN_NUM_GPIOS);
#endif
+#if defined(CONFIG_PWM)
+ struct pwm_chip pchip;
+ boolpwm_enabled;
+ atomic_tpwm_pin_busy;
+#endif
+ unsigned intpwm_refclk_freq;
};
static const struct regmap_range ti_sn65dsi86_volatile_ranges[] = {
@@ -190,6 +215,21 @@ static const struct regmap_config
ti_sn65dsi86_regmap_config = {
.cache_type = REGCACHE_NONE,
};
+static int ti_sn65dsi86_read_u16(struct ti_sn65dsi86 *pdata,
+unsigned int reg, u16 *val)
+{
+ u8 buf[2];
+ int ret;
+
+ ret = regmap_bulk_read(pdata->regmap, reg, buf, ARRAY_SIZE(buf));
+ if (ret)
+ return ret;
+
+ *val = buf[0] | (buf[1] << 8);
+
+ return 0;
+}
+
static void ti_sn65dsi86_write_u16(struct ti_sn65dsi86 *pdata,
unsigned int reg, u16 val)
{
@@ -254,6 +294,12 @@ static void ti_sn_bridge_set_refclk_freq(struct
ti_sn65dsi86 *pdata)
regmap_update_bits(pdata->regmap, SN_DPPLL_SRC_REG, REFCLK_FREQ_MASK,
REFCLK_FREQ(i));
+
+ /*
+* The PWM refclk is based on the value written to SN_DPPLL_SRC_REG,
+* regardless of its actual sourcing.
+*/
+ pdata->pwm_refclk_freq = ti_sn_bridge_refclk_lut[i];
}
static void ti_sn65dsi86_enable_comms(struct ti_sn65dsi86 *pdata)
@@ -1260,9 +1306,289 @@ static struct auxiliary_driver ti_sn_bridge_driver = {
};
/*
[PATCH v6 1/3] pwm: Introduce single-PWM of_xlate function
The existing pxa driver and the upcoming addition of PWM support in the
TI sn565dsi86 DSI/eDP bridge driver both has a single PWM channel and
thereby a need for a of_xlate function with the period as its single
argument.
Introduce a common helper function in the core that can be used as
of_xlate by such drivers and migrate the pxa driver to use this.
Signed-off-by: Bjorn Andersson
---
Changes since v4:
- None
drivers/pwm/core.c| 26 ++
drivers/pwm/pwm-pxa.c | 16 +---
include/linux/pwm.h | 2 ++
3 files changed, 29 insertions(+), 15 deletions(-)
diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
index 4527f09a5c50..2c6b155002a2 100644
--- a/drivers/pwm/core.c
+++ b/drivers/pwm/core.c
@@ -152,6 +152,32 @@ of_pwm_xlate_with_flags(struct pwm_chip *pc, const struct
of_phandle_args *args)
}
EXPORT_SYMBOL_GPL(of_pwm_xlate_with_flags);
+struct pwm_device *
+of_pwm_single_xlate(struct pwm_chip *pc, const struct of_phandle_args *args)
+{
+ struct pwm_device *pwm;
+
+ if (pc->of_pwm_n_cells < 1)
+ return ERR_PTR(-EINVAL);
+
+ /* validate that one cell is specified, optionally with flags */
+ if (args->args_count != 1 && args->args_count != 2)
+ return ERR_PTR(-EINVAL);
+
+ pwm = pwm_request_from_chip(pc, 0, NULL);
+ if (IS_ERR(pwm))
+ return pwm;
+
+ pwm->args.period = args->args[0];
+ pwm->args.polarity = PWM_POLARITY_NORMAL;
+
+ if (args->args_count == 2 && args->args[2] & PWM_POLARITY_INVERTED)
+ pwm->args.polarity = PWM_POLARITY_INVERSED;
+
+ return pwm;
+}
+EXPORT_SYMBOL_GPL(of_pwm_single_xlate);
+
static void of_pwmchip_add(struct pwm_chip *chip)
{
if (!chip->dev || !chip->dev->of_node)
diff --git a/drivers/pwm/pwm-pxa.c b/drivers/pwm/pwm-pxa.c
index a9efdcf839ae..238ec88c130b 100644
--- a/drivers/pwm/pwm-pxa.c
+++ b/drivers/pwm/pwm-pxa.c
@@ -148,20 +148,6 @@ static const struct platform_device_id
*pxa_pwm_get_id_dt(struct device *dev)
return id ? id->data : NULL;
}
-static struct pwm_device *
-pxa_pwm_of_xlate(struct pwm_chip *pc, const struct of_phandle_args *args)
-{
- struct pwm_device *pwm;
-
- pwm = pwm_request_from_chip(pc, 0, NULL);
- if (IS_ERR(pwm))
- return pwm;
-
- pwm->args.period = args->args[0];
-
- return pwm;
-}
-
static int pwm_probe(struct platform_device *pdev)
{
const struct platform_device_id *id = platform_get_device_id(pdev);
@@ -187,7 +173,7 @@ static int pwm_probe(struct platform_device *pdev)
pc->chip.npwm = (id->driver_data & HAS_SECONDARY_PWM) ? 2 : 1;
if (IS_ENABLED(CONFIG_OF)) {
- pc->chip.of_xlate = pxa_pwm_of_xlate;
+ pc->chip.of_xlate = of_pwm_single_xlate;
pc->chip.of_pwm_n_cells = 1;
}
diff --git a/include/linux/pwm.h b/include/linux/pwm.h
index 725c9b784e60..dd51d4931fdc 100644
--- a/include/linux/pwm.h
+++ b/include/linux/pwm.h
@@ -414,6 +414,8 @@ struct pwm_device *pwm_request_from_chip(struct pwm_chip
*chip,
struct pwm_device *of_pwm_xlate_with_flags(struct pwm_chip *pc,
const struct of_phandle_args *args);
+struct pwm_device *of_pwm_single_xlate(struct pwm_chip *pc,
+ const struct of_phandle_args *args);
struct pwm_device *pwm_get(struct device *dev, const char *con_id);
struct pwm_device *of_pwm_get(struct device *dev, struct device_node *np,
--
2.32.0
[v2 PATCH 3/3] drm/mediatek: Fix cursor plane is not config when primary is updating
If cursor plane has updated but primary plane config task is not
finished, mtk_drm_crtc_update_config will call mbox_flush() to clear
all task in current GCE thread and let cursor plane re-send a new
GCE task with cursor + primary plane config to replace the unfinished
GCE task.
So the plane config flag should not be cleared when mailbox callback
with a error status.
Fixes: 9efb16c2fdd6 ("drm/mediatek: Clear pending flag when cmdq packet is
done")
Signed-off-by: jason-jh.lin
---
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index 274e5c67507d..b96dbc867890 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -281,6 +281,9 @@ static void ddp_cmdq_cb(struct mbox_client *cl, void *mssg)
struct mtk_crtc_state *state;
unsigned int i;
+ if (data->sta < 0)
+ return;
+
state = to_mtk_crtc_state(mtk_crtc->base.state);
state->pending_config = false;
--
2.18.0
[v2 PATCH 1/3] drm/mediatek: Fix crash at using pkt->cl->chan in cmdq_pkt_finalize
Because mtk_drm_crtc_create_pkt didn't assign pkt->cl, it will
crash at using pkt->cl->chan in cmdq_pkt_finalize.
So add struct cmdq_client and let mtk_drm_crtc instance define
cmdq_client as:
struct mtk_drm_crtc {
/* client instance data */
struct cmdq_client cmdq_client;
};
and in rx_callback function can use pkt->cl to get
struct cmdq_client.
Fixes: f4be17cd5b14 ("drm/mediatek: Remove struct cmdq_client")
Signed-off-by: jason-jh.lin
---
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 73 +
1 file changed, 38 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index 5f81489fc60c..411d99fcbb8f 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -52,8 +52,7 @@ struct mtk_drm_crtc {
boolpending_async_planes;
#if IS_REACHABLE(CONFIG_MTK_CMDQ)
- struct mbox_client cmdq_cl;
- struct mbox_chan*cmdq_chan;
+ struct cmdq_client cmdq_client;
struct cmdq_pkt cmdq_handle;
u32 cmdq_event;
u32 cmdq_vblank_cnt;
@@ -227,8 +226,8 @@ struct mtk_ddp_comp *mtk_drm_ddp_comp_for_plane(struct
drm_crtc *crtc,
}
#if IS_REACHABLE(CONFIG_MTK_CMDQ)
-static int mtk_drm_cmdq_pkt_create(struct mbox_chan *chan, struct cmdq_pkt
*pkt,
- size_t size)
+static int mtk_drm_cmdq_pkt_create(struct cmdq_client *client, struct cmdq_pkt
*pkt,
+ size_t size)
{
struct device *dev;
dma_addr_t dma_addr;
@@ -239,8 +238,9 @@ static int mtk_drm_cmdq_pkt_create(struct mbox_chan *chan,
struct cmdq_pkt *pkt,
return -ENOMEM;
}
pkt->buf_size = size;
+ pkt->cl = (void *)client;
- dev = chan->mbox->dev;
+ dev = client->chan->mbox->dev;
dma_addr = dma_map_single(dev, pkt->va_base, pkt->buf_size,
DMA_TO_DEVICE);
if (dma_mapping_error(dev, dma_addr)) {
@@ -255,9 +255,11 @@ static int mtk_drm_cmdq_pkt_create(struct mbox_chan *chan,
struct cmdq_pkt *pkt,
return 0;
}
-static void mtk_drm_cmdq_pkt_destroy(struct mbox_chan *chan, struct cmdq_pkt
*pkt)
+static void mtk_drm_cmdq_pkt_destroy(struct cmdq_pkt *pkt)
{
- dma_unmap_single(chan->mbox->dev, pkt->pa_base, pkt->buf_size,
+ struct cmdq_client *client = (struct cmdq_client *)pkt->cl;
+
+ dma_unmap_single(client->chan->mbox->dev, pkt->pa_base, pkt->buf_size,
DMA_TO_DEVICE);
kfree(pkt->va_base);
kfree(pkt);
@@ -265,8 +267,9 @@ static void mtk_drm_cmdq_pkt_destroy(struct mbox_chan
*chan, struct cmdq_pkt *pk
static void ddp_cmdq_cb(struct mbox_client *cl, void *mssg)
{
- struct mtk_drm_crtc *mtk_crtc = container_of(cl, struct mtk_drm_crtc,
cmdq_cl);
struct cmdq_cb_data *data = mssg;
+ struct cmdq_client *cmdq_cl = container_of(cl, struct cmdq_client,
client);
+ struct mtk_drm_crtc *mtk_crtc = container_of(cmdq_cl, struct
mtk_drm_crtc, cmdq_client);
struct mtk_crtc_state *state;
unsigned int i;
@@ -299,7 +302,7 @@ static void ddp_cmdq_cb(struct mbox_client *cl, void *mssg)
}
mtk_crtc->cmdq_vblank_cnt = 0;
- mtk_drm_cmdq_pkt_destroy(mtk_crtc->cmdq_chan, data->pkt);
+ mtk_drm_cmdq_pkt_destroy(data->pkt);
}
#endif
@@ -550,24 +553,24 @@ static void mtk_drm_crtc_update_config(struct
mtk_drm_crtc *mtk_crtc,
mtk_mutex_release(mtk_crtc->mutex);
}
#if IS_REACHABLE(CONFIG_MTK_CMDQ)
- if (mtk_crtc->cmdq_chan) {
- mbox_flush(mtk_crtc->cmdq_chan, 2000);
+ if (mtk_crtc->cmdq_client.chan) {
+ mbox_flush(mtk_crtc->cmdq_client.chan, 2000);
cmdq_handle->cmd_buf_size = 0;
cmdq_pkt_clear_event(cmdq_handle, mtk_crtc->cmdq_event);
cmdq_pkt_wfe(cmdq_handle, mtk_crtc->cmdq_event, false);
mtk_crtc_ddp_config(crtc, cmdq_handle);
cmdq_pkt_finalize(cmdq_handle);
- dma_sync_single_for_device(mtk_crtc->cmdq_chan->mbox->dev,
- cmdq_handle->pa_base,
- cmdq_handle->cmd_buf_size,
- DMA_TO_DEVICE);
+
dma_sync_single_for_device(mtk_crtc->cmdq_client.chan->mbox->dev,
+ cmdq_handle->pa_base,
+ cmdq_handle->cmd_buf_size,
+ DMA_TO_DEVICE);
/*
* CMDQ command should execute in next vblank,
* If it fail to execute in next 2 vblank, timeout happen.
*/
[v2 PATCH 2/3] drm/mediatek: Fix pkt buf alloc once but free many times
Because mtk_drm_crt_cmdq_pkt_create is called once
in mtk_drm_crtc_create, the pkt should not be destroy
at ddp_cmdq_cb.
So move mtk_drm_crtc_pkt_destroy to mtk_drm_crtc_destroy.
Fixes: bc9241be73d9 ("drm/mediatek: Add cmdq_handle in mtk_crtc")
Signed-off-by: jason-jh.lin
Reviewed-by: Chun-Kuang Hu
---
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 29 +++--
1 file changed, 18 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index 411d99fcbb8f..274e5c67507d 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -108,12 +108,30 @@ static void mtk_drm_finish_page_flip(struct mtk_drm_crtc
*mtk_crtc)
}
}
+#if IS_REACHABLE(CONFIG_MTK_CMDQ)
+static void mtk_drm_cmdq_pkt_destroy(struct cmdq_pkt *pkt)
+{
+ struct cmdq_client *client = (struct cmdq_client *)pkt->cl;
+
+ dma_unmap_single(client->chan->mbox->dev, pkt->pa_base, pkt->buf_size,
+DMA_TO_DEVICE);
+ kfree(pkt->va_base);
+ kfree(pkt);
+}
+#endif
+
static void mtk_drm_crtc_destroy(struct drm_crtc *crtc)
{
struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc);
mtk_mutex_put(mtk_crtc->mutex);
+#if IS_REACHABLE(CONFIG_MTK_CMDQ)
+ mtk_drm_cmdq_pkt_destroy(_crtc->cmdq_handle);
+ if (mtk_crtc->cmdq_client.chan)
+ mbox_free_channel(mtk_crtc->cmdq_client.chan);
+ mtk_crtc->cmdq_client.chan = NULL;
+#endif
drm_crtc_cleanup(crtc);
}
@@ -255,16 +273,6 @@ static int mtk_drm_cmdq_pkt_create(struct cmdq_client
*client, struct cmdq_pkt *
return 0;
}
-static void mtk_drm_cmdq_pkt_destroy(struct cmdq_pkt *pkt)
-{
- struct cmdq_client *client = (struct cmdq_client *)pkt->cl;
-
- dma_unmap_single(client->chan->mbox->dev, pkt->pa_base, pkt->buf_size,
-DMA_TO_DEVICE);
- kfree(pkt->va_base);
- kfree(pkt);
-}
-
static void ddp_cmdq_cb(struct mbox_client *cl, void *mssg)
{
struct cmdq_cb_data *data = mssg;
@@ -302,7 +310,6 @@ static void ddp_cmdq_cb(struct mbox_client *cl, void *mssg)
}
mtk_crtc->cmdq_vblank_cnt = 0;
- mtk_drm_cmdq_pkt_destroy(data->pkt);
}
#endif
--
2.18.0
[v2 PATCH 0/3] Fix the issues caused by CMDQ refinement of mtk-drm
Change in v2: - cmdq_ddp_cb should use struct mbox_clinet to find struct cmdq_client, and then use struct cmdq_clint to find struct mtk_drm_crtc - change data.sta checking condition to stadard error checking jason-jh.lin (3): drm/mediatek: Fix crash at using pkt->cl->chan in cmdq_pkt_finalize drm/mediatek: Fix pkt buf alloc once but free many times drm/mediatek: Fix cursor plane is not config when primary is updating drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 95 ++--- 1 file changed, 54 insertions(+), 41 deletions(-) -- 2.18.0
Re: [PATCH v4 00/24] drm/bridge: Make panel and bridge probe order consistent
On Wed, Sep 29, 2021 at 4:20 PM Rob Clark wrote: > On Wed, Sep 29, 2021 at 2:51 PM John Stultz wrote: > > On Wed, Sep 29, 2021 at 2:32 PM John Stultz wrote: > > > On Wed, Sep 29, 2021 at 2:27 PM John Stultz > > > wrote: > > > > On Fri, Sep 10, 2021 at 3:12 AM Maxime Ripard wrote: > > > > > The best practice to avoid those issues is to register its functions > > > > > only after > > > > > all its dependencies are live. We also shouldn't wait any longer than > > > > > we should > > > > > to play nice with the other components that are waiting for us, so in > > > > > our case > > > > > that would mean moving the DSI device registration to the bridge > > > > > probe. > > > > > > > > > > I also had a look at all the DSI hosts, and it seems that exynos, > > > > > kirin and msm > > > > > would be affected by this and wouldn't probe anymore after those > > > > > changes. > > > > > Exynos and kirin seems to be simple enough for a mechanical change > > > > > (that still > > > > > requires to be tested), but the changes in msm seemed to be far more > > > > > important > > > > > and I wasn't confortable doing them. > > > > > > > > > > > > Hey Maxime, > > > > Sorry for taking so long to get to this, but now that plumbers is > > > > over I've had a chance to check it out on kirin > > > > > > > > Rob Clark pointed me to his branch with some fixups here: > > > > > > > > https://gitlab.freedesktop.org/robclark/msm/-/commits/for-mripard/bridge-rework > > > > > > > > But trying to boot hikey with that, I see the following loop > > > > indefinitely: > > > > [4.632132] adv7511 2-0039: supply avdd not found, using dummy > > > > regulator > > > > [4.638961] adv7511 2-0039: supply dvdd not found, using dummy > > > > regulator > > > > [4.645741] adv7511 2-0039: supply pvdd not found, using dummy > > > > regulator > > > > [4.652483] adv7511 2-0039: supply a2vdd not found, using dummy > > > > regulator > > > > [4.659342] adv7511 2-0039: supply v3p3 not found, using dummy > > > > regulator > > > > [4.666086] adv7511 2-0039: supply v1p2 not found, using dummy > > > > regulator > > > > [4.681898] adv7511 2-0039: failed to find dsi host > > > > > > I just realized Rob's tree is missing the kirin patch. My apologies! > > > I'll retest and let you know. > > > > Ok, just retested including the kirin patch and unfortunately I'm > > still seeing the same thing. :( > > > > Will dig a bit and let you know when I find more. > > Did you have a chance to test it on anything using drm/msm with DSI > panels? That would at least confirm that I didn't miss anything in > the drm/msm patch to swap the dsi-host vs bridge ordering.. Not a dsi panel, but for what it's worth, I did just test the series with the db845c w/ HDMI using the lt9611 bridge. So at least that is looking ok. thanks -john
[pull] amdgpu drm-fixes-5.15
Hi Dave, Daniel, Fixes for 5.15. The following changes since commit 05812b971c6d605c00987750f422918589aa4486: Merge tag 'drm/tegra/for-5.15-rc3' of ssh://git.freedesktop.org/git/tegra/linux into drm-fixes (2021-09-28 17:08:44 +1000) are available in the Git repository at: https://gitlab.freedesktop.org/agd5f/linux.git tags/amd-drm-fixes-5.15-2021-09-29 for you to fetch changes up to 26db706a6d77b9e184feb11725e97e53b7a89519: drm/amdgpu: force exit gfxoff on sdma resume for rmb s0ix (2021-09-28 14:40:27 -0400) amd-drm-fixes-5.15-2021-09-29: amdgpu: - gart pin count fix - eDP flicker fix - GFX9 MQD fix - Display fixes - Tiling flags fix for pre-GFX9 - SDMA resume fix for S0ix Charlene Liu (1): drm/amd/display: Pass PCI deviceid into DC Hawking Zhang (1): drm/amdgpu: correct initial cp_hqd_quantum for gfx9 Josip Pavic (1): drm/amd/display: initialize backlight_ramping_override to false Leslie Shi (1): drm/amdgpu: fix gart.bo pin_count leak Praful Swarnakar (1): drm/amd/display: Fix Display Flicker on embedded panels Prike Liang (1): drm/amdgpu: force exit gfxoff on sdma resume for rmb s0ix Simon Ser (1): drm/amdgpu: check tiling flags when creating FB on GFX8- drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 31 +++ drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 2 +- drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c| 3 ++- drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 3 ++- drivers/gpu/drm/amd/amdgpu/sdma_v5_2.c| 8 ++ drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 ++ drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c | 15 +-- 7 files changed, 53 insertions(+), 11 deletions(-)
Re: [Freedreno] [PATCH v2 00/22] drm/msm/dpu: switch dpu_plane to be virtual
Hi Dmitry On 2021-07-04 18:20, Dmitry Baryshkov wrote: As discussed on IRC, change dpu_plane implementation to be virtual: register unified planes and select backing SSPP block at runtime. Use msm.dpu_use_virtual_planes=1 to enable usage of virtual planes rather than statically allocated SSPPs at the plane registration. Patches 1-9 move state variables from struct dpu_plane onto the stack allocation. State should not be a part of struct dpu_plane anyway. Patches 10-18 make additional changes to plane code, reworking check, debugfs, dropping old multirec support, which results in patch 19 adding support for virtual planes per se. Patches 20-22 demonstrate my main goal behind reworking dpu_plane support. They change dpu_plane to automatically use one of SSPP block features - multirec, an ability to display two unscaled RGB rectangles using single SSPP block. This allows us to double the amount of created planes. If the user tries to enable more planes than actually supported by the underlying SSPP blocks, atomic_check code would return an error. As you can see, this patchset is not atomic, so different patches can go separately. I am half way through this series and have finished checking patches 1-12 I am okay with patches 1-4, 6-12. Its a reasonable cleanup to make the dpu_plane struct lighter. I need a little more time with the rest as I am comparing the downstream solution against yours. As you mentioned, this patchset is not atomic, hence can you break it up like -> cleanup of dpu_plane struct in one series -> removal of current multirect and current src split which will include patch 5 as well So that the first series can go through and it gives us a little more time to check the second series. Thanks Abhinav Changes since v1: - Add multirec implementation - Added msm.dpu_use_virtual_planes kernel parameter instead of using compile time switch - Changed code to always reallocate SSPPs in the CRTC atomic check to let the kernel pick up the best multirec config. This can be optimized later. - Rework RM SSPP API to always receive plane id - Removed scaler_cfg, pixel_ext and cdp_cfg from struct dpu_plane_state - Made _dpu_scaler_setup() call sspp's setup_scaler and setup_pe - Removed dpu_csc_cfg from dpu_plane The following changes since commit e88bbc91849b2bf57683119c339e52916d34433f: Revert "drm/msm/mdp5: provide dynamic bandwidth management" (2021-06-23 14:06:20 -0700) are available in the Git repository at: https://git.linaro.org/people/dmitry.baryshkov/kernel.git dpu-multirec-2 for you to fetch changes up to 19f6afd40097d4c826e56b8f4a8cbd807f7b61f6: drm/msm/dpu: add multirect support (2021-07-05 04:04:50 +0300) Dmitry Baryshkov (22): drm/msm/dpu: move LUT levels out of QOS config drm/msm/dpu: remove pipe_qos_cfg from struct dpu_plane drm/msm/dpu: drop pipe_name from struct dpu_plane drm/msm/dpu: remove stage_cfg from struct dpu_crtc drm/msm/dpu: rip out master planes support drm/msm/dpu: move dpu_hw_pipe_cfg out of struct dpu_plane drm/msm/dpu: drop scaler config from plane state drm/msm/dpu: drop dpu_csc_cfg from dpu_plane drm/msm/dpu: remove dpu_hw_pipe_cdp_cfg from dpu_plane drm/msm/dpu: don't cache pipe->cap->features in dpu_plane drm/msm/dpu: don't cache pipe->cap->sblk in dpu_plane drm/msm/dpu: rip out debugfs support from dpu_plane drm/msm/dpu: drop src_split and multirect check from dpu_crtc_atomic_check drm/msm/dpu: add list of supported formats to the DPU caps drm/msm/dpu: simplify DPU_SSPP features checks drm/msm/dpu: do not limit the zpos property drm/msm/dpu: add support for SSPP allocation to RM drm/msm/dpu: move pipe_hw to dpu_plane_state drm/msm/dpu: add support for virtualized planes drm/msm/dpu: fix smart dma support drm/msm/dpu: fix CDP setup to account for multirect index drm/msm/dpu: add multirect support drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 261 +++- drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h | 2 - drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 20 +- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 20 +- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c| 41 +- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h| 52 +- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.c| 2 +- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.h| 2 +- drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c| 234 --- drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h| 70 +- drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 851 +++-- drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h | 75 +-- drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 81 +++ drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h | 6 + 14 files changed, 793 insertions(+), 924 deletions(-)
Re: [PATCH 2/4] amdgpu_ucode: reduce number of pr_debug calls
On Wed, 2021-09-29 at 19:44 -0600, Jim Cromie wrote:
> There are blocks of DRM_DEBUG calls, consolidate their args into
> single calls. With dynamic-debug in use, each callsite consumes 56
> bytes of callsite data, and this patch removes about 65 calls, so
> it saves ~3.5kb.
>
> no functional changes.
No functional change, but an output logging content change.
> RFC: this creates multi-line log messages, does that break any syslog
> conventions ?
It does change the output as each individual DRM_DEBUG is a call to
__drm_dbg which is effectively:
printk(KERN_DEBUG "[" DRM_NAME ":%ps] %pV",
__builtin_return_address(0), );
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c
[]
> @@ -30,17 +30,26 @@
>
>
> static void amdgpu_ucode_print_common_hdr(const struct
> common_firmware_header *hdr)
> {
> - DRM_DEBUG("size_bytes: %u\n", le32_to_cpu(hdr->size_bytes));
> - DRM_DEBUG("header_size_bytes: %u\n",
> le32_to_cpu(hdr->header_size_bytes));
[]
> + DRM_DEBUG("size_bytes: %u\n"
> + "header_size_bytes: %u\n"
etc...
[PATCH 4/4] i915/gvt: remove spaces in pr_debug "gvt: core:" etc prefixes
Taking embedded spaces out of existing prefixes makes them better
class-prefixes; simplifying the extra quoting needed otherwise:
$> echo format "^gvt: core:" +p >control
vs
$> echo format ^gvt:core: +p >control
Dropping the internal spaces means that quotes are only needed when
the trailing space is required; they more distinctively signal that
requirement.
Consider a generic drm-debug example:
# turn off ATOMIC reports
echo format "^drm:atomic: " -p > control
# turn off all ATOMIC:* reports, including any sub-categories
echo format "^drm:atomic:" -p > control
# turn on ATOMIC:FAIL: reports
echo format "^drm:atomic:fail: " +p > control
Removing embedded spaces in the class-prefixes simplifies the
corresponding match-prefix. This means that "quoted" match-prefixes
are only needed when the trailing space is desired, in order to
exclude explicitly sub-categorized pr-debugs; in this example,
"drm:atomic:fail:".
Signed-off-by: Jim Cromie
---
---
drivers/gpu/drm/i915/gvt/debug.h | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/debug.h b/drivers/gpu/drm/i915/gvt/debug.h
index c6027125c1ec..bbecc279e077 100644
--- a/drivers/gpu/drm/i915/gvt/debug.h
+++ b/drivers/gpu/drm/i915/gvt/debug.h
@@ -36,30 +36,30 @@ do {
\
} while (0)
#define gvt_dbg_core(fmt, args...) \
- pr_debug("gvt: core: "fmt, ##args)
+ pr_debug("gvt:core: " fmt, ##args)
#define gvt_dbg_irq(fmt, args...) \
- pr_debug("gvt: irq: "fmt, ##args)
+ pr_debug("gvt:irq: " fmt, ##args)
#define gvt_dbg_mm(fmt, args...) \
- pr_debug("gvt: mm: "fmt, ##args)
+ pr_debug("gvt:mm: " fmt, ##args)
#define gvt_dbg_mmio(fmt, args...) \
- pr_debug("gvt: mmio: "fmt, ##args)
+ pr_debug("gvt:mmio: " fmt, ##args)
#define gvt_dbg_dpy(fmt, args...) \
- pr_debug("gvt: dpy: "fmt, ##args)
+ pr_debug("gvt:dpy: " fmt, ##args)
#define gvt_dbg_el(fmt, args...) \
- pr_debug("gvt: el: "fmt, ##args)
+ pr_debug("gvt:el: " fmt, ##args)
#define gvt_dbg_sched(fmt, args...) \
- pr_debug("gvt: sched: "fmt, ##args)
+ pr_debug("gvt:sched: " fmt, ##args)
#define gvt_dbg_render(fmt, args...) \
- pr_debug("gvt: render: "fmt, ##args)
+ pr_debug("gvt:render: " fmt, ##args)
#define gvt_dbg_cmd(fmt, args...) \
- pr_debug("gvt: cmd: "fmt, ##args)
+ pr_debug("gvt:cmd: " fmt, ##args)
#endif
--
2.31.1
[PATCH 3/4] nouveau: fold multiple DRM_DEBUG_DRIVERs together
With DRM_USE_DYNAMIC_DEBUG, each callsite record requires 56 bytes.
We can combine 12 into one here and save ~620 bytes.
Signed-off-by: Jim Cromie
---
drivers/gpu/drm/nouveau/nouveau_drm.c | 36 +--
1 file changed, 23 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index 1f828c9f691c..d9fbd249dbaa 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -1242,19 +1242,29 @@ nouveau_drm_pci_table[] = {
static void nouveau_display_options(void)
{
- DRM_DEBUG_DRIVER("Loading Nouveau with parameters:\n");
-
- DRM_DEBUG_DRIVER("... tv_disable : %d\n", nouveau_tv_disable);
- DRM_DEBUG_DRIVER("... ignorelid: %d\n", nouveau_ignorelid);
- DRM_DEBUG_DRIVER("... duallink : %d\n", nouveau_duallink);
- DRM_DEBUG_DRIVER("... nofbaccel: %d\n", nouveau_nofbaccel);
- DRM_DEBUG_DRIVER("... config : %s\n", nouveau_config);
- DRM_DEBUG_DRIVER("... debug: %s\n", nouveau_debug);
- DRM_DEBUG_DRIVER("... noaccel : %d\n", nouveau_noaccel);
- DRM_DEBUG_DRIVER("... modeset : %d\n", nouveau_modeset);
- DRM_DEBUG_DRIVER("... runpm: %d\n", nouveau_runtime_pm);
- DRM_DEBUG_DRIVER("... vram_pushbuf : %d\n", nouveau_vram_pushbuf);
- DRM_DEBUG_DRIVER("... hdmimhz : %d\n", nouveau_hdmimhz);
+ DRM_DEBUG_DRIVER("Loading Nouveau with parameters:\n"
+"... tv_disable : %d\n"
+"... ignorelid: %d\n"
+"... duallink : %d\n"
+"... nofbaccel: %d\n"
+"... config : %s\n"
+"... debug: %s\n"
+"... noaccel : %d\n"
+"... modeset : %d\n"
+"... runpm: %d\n"
+"... vram_pushbuf : %d\n"
+"... hdmimhz : %d\n"
+, nouveau_tv_disable
+, nouveau_ignorelid
+, nouveau_duallink
+, nouveau_nofbaccel
+, nouveau_config
+, nouveau_debug
+, nouveau_noaccel
+, nouveau_modeset
+, nouveau_runtime_pm
+, nouveau_vram_pushbuf
+, nouveau_hdmimhz);
}
static const struct dev_pm_ops nouveau_pm_ops = {
--
2.31.1
[PATCH 2/4] amdgpu_ucode: reduce number of pr_debug calls
There are blocks of DRM_DEBUG calls, consolidate their args into
single calls. With dynamic-debug in use, each callsite consumes 56
bytes of callsite data, and this patch removes about 65 calls, so
it saves ~3.5kb.
no functional changes.
RFC: this creates multi-line log messages, does that break any syslog
conventions ?
Signed-off-by: Jim Cromie
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c | 293 --
1 file changed, 158 insertions(+), 135 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c
index abd8469380e5..411179142a6e 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c
@@ -30,17 +30,26 @@
static void amdgpu_ucode_print_common_hdr(const struct common_firmware_header
*hdr)
{
- DRM_DEBUG("size_bytes: %u\n", le32_to_cpu(hdr->size_bytes));
- DRM_DEBUG("header_size_bytes: %u\n",
le32_to_cpu(hdr->header_size_bytes));
- DRM_DEBUG("header_version_major: %u\n",
le16_to_cpu(hdr->header_version_major));
- DRM_DEBUG("header_version_minor: %u\n",
le16_to_cpu(hdr->header_version_minor));
- DRM_DEBUG("ip_version_major: %u\n", le16_to_cpu(hdr->ip_version_major));
- DRM_DEBUG("ip_version_minor: %u\n", le16_to_cpu(hdr->ip_version_minor));
- DRM_DEBUG("ucode_version: 0x%08x\n", le32_to_cpu(hdr->ucode_version));
- DRM_DEBUG("ucode_size_bytes: %u\n", le32_to_cpu(hdr->ucode_size_bytes));
- DRM_DEBUG("ucode_array_offset_bytes: %u\n",
- le32_to_cpu(hdr->ucode_array_offset_bytes));
- DRM_DEBUG("crc32: 0x%08x\n", le32_to_cpu(hdr->crc32));
+ DRM_DEBUG("size_bytes: %u\n"
+ "header_size_bytes: %u\n"
+ "header_version_major: %u\n"
+ "header_version_minor: %u\n"
+ "ip_version_major: %u\n"
+ "ip_version_minor: %u\n"
+ "ucode_version: 0x%08x\n"
+ "ucode_size_bytes: %u\n"
+ "ucode_array_offset_bytes: %u\n"
+ "crc32: 0x%08x\n",
+ le32_to_cpu(hdr->size_bytes),
+ le32_to_cpu(hdr->header_size_bytes),
+ le16_to_cpu(hdr->header_version_major),
+ le16_to_cpu(hdr->header_version_minor),
+ le16_to_cpu(hdr->ip_version_major),
+ le16_to_cpu(hdr->ip_version_minor),
+ le32_to_cpu(hdr->ucode_version),
+ le32_to_cpu(hdr->ucode_size_bytes),
+ le32_to_cpu(hdr->ucode_array_offset_bytes),
+ le32_to_cpu(hdr->crc32));
}
void amdgpu_ucode_print_mc_hdr(const struct common_firmware_header *hdr)
@@ -55,9 +64,9 @@ void amdgpu_ucode_print_mc_hdr(const struct
common_firmware_header *hdr)
const struct mc_firmware_header_v1_0 *mc_hdr =
container_of(hdr, struct mc_firmware_header_v1_0,
header);
- DRM_DEBUG("io_debug_size_bytes: %u\n",
- le32_to_cpu(mc_hdr->io_debug_size_bytes));
- DRM_DEBUG("io_debug_array_offset_bytes: %u\n",
+ DRM_DEBUG("io_debug_size_bytes: %u\n"
+ "io_debug_array_offset_bytes: %u\n",
+ le32_to_cpu(mc_hdr->io_debug_size_bytes),
le32_to_cpu(mc_hdr->io_debug_array_offset_bytes));
} else {
DRM_ERROR("Unknown MC ucode version: %u.%u\n", version_major,
version_minor);
@@ -82,13 +91,17 @@ void amdgpu_ucode_print_smc_hdr(const struct
common_firmware_header *hdr)
switch (version_minor) {
case 0:
v2_0_hdr = container_of(hdr, struct
smc_firmware_header_v2_0, v1_0.header);
- DRM_DEBUG("ppt_offset_bytes: %u\n",
le32_to_cpu(v2_0_hdr->ppt_offset_bytes));
- DRM_DEBUG("ppt_size_bytes: %u\n",
le32_to_cpu(v2_0_hdr->ppt_size_bytes));
+ DRM_DEBUG("ppt_offset_bytes: %u\n"
+ "ppt_size_bytes: %u\n",
+ le32_to_cpu(v2_0_hdr->ppt_offset_bytes),
+ le32_to_cpu(v2_0_hdr->ppt_size_bytes));
break;
case 1:
v2_1_hdr = container_of(hdr, struct
smc_firmware_header_v2_1, v1_0.header);
- DRM_DEBUG("pptable_count: %u\n",
le32_to_cpu(v2_1_hdr->pptable_count));
- DRM_DEBUG("pptable_entry_offset: %u\n",
le32_to_cpu(v2_1_hdr->pptable_entry_offset));
+ DRM_DEBUG("pptable_count: %u\n"
+ "pptable_entry_offset: %u\n",
+ le32_to_cpu(v2_1_hdr->pptable_count),
+ le32_to_cpu(v2_1_hdr->pptable_entry_offset));
break;
default:
break;
@@ -111,10 +124,12 @@ void
[PATCH 1/4] drm: fix doc grammar error
no code changes, good for rc Signed-off-by: Jim Cromie --- include/drm/drm_drv.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h index 0cd95953cdf5..4b29261c4537 100644 --- a/include/drm/drm_drv.h +++ b/include/drm/drm_drv.h @@ -486,7 +486,7 @@ void *__devm_drm_dev_alloc(struct device *parent, * @type: the type of the struct which contains struct _device * @member: the name of the _device within @type. * - * This allocates and initialize a new DRM device. No device registration is done. + * This allocates and initializes a new DRM device. No device registration is done. * Call drm_dev_register() to advertice the device to user space and register it * with other core subsystems. This should be done last in the device * initialization sequence to make sure userspace can't access an inconsistent -- 2.31.1
[PATCH 0/4] drm: maintenance patches for 5.15-rcX
hi drm folks, Heres a small set of assorted patches which are IMO suitable for rcX; one doc fix, 2 patches folding multiple DBGs together, and a format string modification. Jim Cromie (4): drm: fix doc grammar error amdgpu_ucode: reduce number of pr_debug calls nouveau: fold multiple DRM_DEBUG_DRIVERs together i915/gvt: remove spaces in pr_debug "gvt: core:" etc prefixes drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c | 293 -- drivers/gpu/drm/i915/gvt/debug.h | 18 +- drivers/gpu/drm/nouveau/nouveau_drm.c | 36 ++- include/drm/drm_drv.h | 2 +- 4 files changed, 191 insertions(+), 158 deletions(-) -- 2.31.1
Re: [PATCH v13 16/35] usb: chipidea: tegra: Add runtime PM and OPP support
27.09.2021 01:40, Dmitry Osipenko пишет: > The Tegra USB controller belongs to the core power domain and we're going > to enable GENPD support for the core domain. Now USB controller must be > resumed using runtime PM API in order to initialize the USB power state. > We already support runtime PM for the CI device, but CI's PM is separated > from the RPM managed by tegra-usb driver. Add runtime PM and OPP support > to the driver. > > Signed-off-by: Dmitry Osipenko > --- > drivers/usb/chipidea/ci_hdrc_tegra.c | 53 > 1 file changed, 46 insertions(+), 7 deletions(-) Peter Chen, could you please ack this patch? Thanks in advance!
[PATCH v2 2/3] dt-bindings: drm/bridge: ps8640: Add aux-bus child
dp-aux-bus.yaml says we can list an eDP panel as a child of
an eDP controller node to represent the fact that the panel
is connected to the controller's DP AUX bus.
Let's add it to the ps8640 bindings.
Signed-off-by: Philip Chen
---
(no changes since v1)
.../bindings/display/bridge/ps8640.yaml | 19 ++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/display/bridge/ps8640.yaml
b/Documentation/devicetree/bindings/display/bridge/ps8640.yaml
index fce82b605c8b..cdaf7a7a8f88 100644
--- a/Documentation/devicetree/bindings/display/bridge/ps8640.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/ps8640.yaml
@@ -40,6 +40,9 @@ properties:
vdd33-supply:
description: Regulator for 3.3V digital core power.
+ aux-bus:
+$ref: /schemas/display/dp-aux-bus.yaml#
+
ports:
$ref: /schemas/graph.yaml#/properties/ports
@@ -98,7 +101,21 @@ examples:
reg = <1>;
ps8640_out: endpoint {
remote-endpoint = <_in>;
- };
+};
+};
+};
+
+aux-bus {
+panel {
+compatible = "boe,nv133fhm-n62";
+power-supply = <_dx_edp>;
+backlight = <>;
+
+port {
+panel_in: endpoint {
+remote-endpoint = <_out>;
+};
+};
};
};
};
--
2.33.0.685.g46640cef36-goog
Re: [PATCH v2] drm/msm/dp: only signal audio when disconnected detected at dp_pm_resume
Quoting Kuogee Hsieh (2021-09-29 09:17:04)
> Currently there is audio not working problem after system resume from suspend
> if hdmi monitor stay plugged in at DUT. However this problem does not happen
> at normal operation but at a particular test case. The root cause is DP driver
> signal audio with connected state at resume which trigger audio trying to
> setup
> audio data path through DP main link but failed due to display port is not
> setup
> and enabled by upper layer framework yet. This patch only have DP driver
> signal
> audio only when DP is in disconnected state so that audio option shows correct
> state after system resume. DP driver will not signal audio with connected
> state
> until display enabled executed by upper layer framework where display port is
> setup completed and main link is running.
>
> Changes in V2:
> -- add details commit text
>
> Fixes: 078867ce04ed ("drm/msm/dp: signal audio plugged change at
> dp_pm_resume")
> Signed-off-by: Kuogee Hsieh
> ---
Reviewed-by: Stephen Boyd
Re: [PATCH v4 00/24] drm/bridge: Make panel and bridge probe order consistent
On Wed, Sep 29, 2021 at 2:51 PM John Stultz wrote: > > On Wed, Sep 29, 2021 at 2:32 PM John Stultz wrote: > > On Wed, Sep 29, 2021 at 2:27 PM John Stultz wrote: > > > On Fri, Sep 10, 2021 at 3:12 AM Maxime Ripard wrote: > > > > The best practice to avoid those issues is to register its functions > > > > only after > > > > all its dependencies are live. We also shouldn't wait any longer than > > > > we should > > > > to play nice with the other components that are waiting for us, so in > > > > our case > > > > that would mean moving the DSI device registration to the bridge probe. > > > > > > > > I also had a look at all the DSI hosts, and it seems that exynos, kirin > > > > and msm > > > > would be affected by this and wouldn't probe anymore after those > > > > changes. > > > > Exynos and kirin seems to be simple enough for a mechanical change > > > > (that still > > > > requires to be tested), but the changes in msm seemed to be far more > > > > important > > > > and I wasn't confortable doing them. > > > > > > > > > Hey Maxime, > > > Sorry for taking so long to get to this, but now that plumbers is > > > over I've had a chance to check it out on kirin > > > > > > Rob Clark pointed me to his branch with some fixups here: > > > > > > https://gitlab.freedesktop.org/robclark/msm/-/commits/for-mripard/bridge-rework > > > > > > But trying to boot hikey with that, I see the following loop indefinitely: > > > [4.632132] adv7511 2-0039: supply avdd not found, using dummy > > > regulator > > > [4.638961] adv7511 2-0039: supply dvdd not found, using dummy > > > regulator > > > [4.645741] adv7511 2-0039: supply pvdd not found, using dummy > > > regulator > > > [4.652483] adv7511 2-0039: supply a2vdd not found, using dummy > > > regulator > > > [4.659342] adv7511 2-0039: supply v3p3 not found, using dummy > > > regulator > > > [4.666086] adv7511 2-0039: supply v1p2 not found, using dummy > > > regulator > > > [4.681898] adv7511 2-0039: failed to find dsi host > > > > I just realized Rob's tree is missing the kirin patch. My apologies! > > I'll retest and let you know. > > Ok, just retested including the kirin patch and unfortunately I'm > still seeing the same thing. :( > > Will dig a bit and let you know when I find more. Hey Maxime! I chased down the issue. The dsi probe code was still calling drm_of_find_panel_or_bridge() in order to succeed. I've moved the logic that looks for the bridge into the bridge_init and with that it seems to work. Feel free (assuming it looks ok) to fold this change into your kirin patch: https://git.linaro.org/people/john.stultz/android-dev.git/commit/?id=4a35ccc4d7a53f68d6d93da3b47e232a7c75b91d thanks -john
Re: [PATCH v4 00/24] drm/bridge: Make panel and bridge probe order consistent
On Wed, Sep 29, 2021 at 4:20 PM Rob Clark wrote: > On Wed, Sep 29, 2021 at 2:51 PM John Stultz wrote: > > On Wed, Sep 29, 2021 at 2:32 PM John Stultz wrote: > > > On Wed, Sep 29, 2021 at 2:27 PM John Stultz > > > wrote: > > > > On Fri, Sep 10, 2021 at 3:12 AM Maxime Ripard wrote: > > > > > The best practice to avoid those issues is to register its functions > > > > > only after > > > > > all its dependencies are live. We also shouldn't wait any longer than > > > > > we should > > > > > to play nice with the other components that are waiting for us, so in > > > > > our case > > > > > that would mean moving the DSI device registration to the bridge > > > > > probe. > > > > > > > > > > I also had a look at all the DSI hosts, and it seems that exynos, > > > > > kirin and msm > > > > > would be affected by this and wouldn't probe anymore after those > > > > > changes. > > > > > Exynos and kirin seems to be simple enough for a mechanical change > > > > > (that still > > > > > requires to be tested), but the changes in msm seemed to be far more > > > > > important > > > > > and I wasn't confortable doing them. > > > > > > > > > > > > Hey Maxime, > > > > Sorry for taking so long to get to this, but now that plumbers is > > > > over I've had a chance to check it out on kirin > > > > > > > > Rob Clark pointed me to his branch with some fixups here: > > > > > > > > https://gitlab.freedesktop.org/robclark/msm/-/commits/for-mripard/bridge-rework > > > > > > > > But trying to boot hikey with that, I see the following loop > > > > indefinitely: > > > > [4.632132] adv7511 2-0039: supply avdd not found, using dummy > > > > regulator > > > > [4.638961] adv7511 2-0039: supply dvdd not found, using dummy > > > > regulator > > > > [4.645741] adv7511 2-0039: supply pvdd not found, using dummy > > > > regulator > > > > [4.652483] adv7511 2-0039: supply a2vdd not found, using dummy > > > > regulator > > > > [4.659342] adv7511 2-0039: supply v3p3 not found, using dummy > > > > regulator > > > > [4.666086] adv7511 2-0039: supply v1p2 not found, using dummy > > > > regulator > > > > [4.681898] adv7511 2-0039: failed to find dsi host > > > > > > I just realized Rob's tree is missing the kirin patch. My apologies! > > > I'll retest and let you know. > > > > Ok, just retested including the kirin patch and unfortunately I'm > > still seeing the same thing. :( > > > > Will dig a bit and let you know when I find more. > > Did you have a chance to test it on anything using drm/msm with DSI > panels? That would at least confirm that I didn't miss anything in > the drm/msm patch to swap the dsi-host vs bridge ordering.. I believe Amit(cc'ed) tried to give it a run on his pocof1, but had some troubles getting it working against a kernel that wasn't suffering other regressions at the moment. Amit/Caleb: Any chance one of you could try again w/ these merged to 5.15-rc3? thanks -john
Re: [PATCH v4 00/24] drm/bridge: Make panel and bridge probe order consistent
On Wed, Sep 29, 2021 at 2:51 PM John Stultz wrote: > > On Wed, Sep 29, 2021 at 2:32 PM John Stultz wrote: > > On Wed, Sep 29, 2021 at 2:27 PM John Stultz wrote: > > > On Fri, Sep 10, 2021 at 3:12 AM Maxime Ripard wrote: > > > > The best practice to avoid those issues is to register its functions > > > > only after > > > > all its dependencies are live. We also shouldn't wait any longer than > > > > we should > > > > to play nice with the other components that are waiting for us, so in > > > > our case > > > > that would mean moving the DSI device registration to the bridge probe. > > > > > > > > I also had a look at all the DSI hosts, and it seems that exynos, kirin > > > > and msm > > > > would be affected by this and wouldn't probe anymore after those > > > > changes. > > > > Exynos and kirin seems to be simple enough for a mechanical change > > > > (that still > > > > requires to be tested), but the changes in msm seemed to be far more > > > > important > > > > and I wasn't confortable doing them. > > > > > > > > > Hey Maxime, > > > Sorry for taking so long to get to this, but now that plumbers is > > > over I've had a chance to check it out on kirin > > > > > > Rob Clark pointed me to his branch with some fixups here: > > > > > > https://gitlab.freedesktop.org/robclark/msm/-/commits/for-mripard/bridge-rework > > > > > > But trying to boot hikey with that, I see the following loop indefinitely: > > > [4.632132] adv7511 2-0039: supply avdd not found, using dummy > > > regulator > > > [4.638961] adv7511 2-0039: supply dvdd not found, using dummy > > > regulator > > > [4.645741] adv7511 2-0039: supply pvdd not found, using dummy > > > regulator > > > [4.652483] adv7511 2-0039: supply a2vdd not found, using dummy > > > regulator > > > [4.659342] adv7511 2-0039: supply v3p3 not found, using dummy > > > regulator > > > [4.666086] adv7511 2-0039: supply v1p2 not found, using dummy > > > regulator > > > [4.681898] adv7511 2-0039: failed to find dsi host > > > > I just realized Rob's tree is missing the kirin patch. My apologies! > > I'll retest and let you know. > > Ok, just retested including the kirin patch and unfortunately I'm > still seeing the same thing. :( > > Will dig a bit and let you know when I find more. Did you have a chance to test it on anything using drm/msm with DSI panels? That would at least confirm that I didn't miss anything in the drm/msm patch to swap the dsi-host vs bridge ordering.. BR, -R
Re: [PATCH v2 2/3] drm/i915/utils: do not depend on config being defined
On Wed, Sep 29, 2021 at 11:08:18PM +0200, Andrzej Hajda wrote:
W dniu 29.09.2021 o 20:33, Lucas De Marchi pisze:
Like the IS_ENABLED() counterpart, we can make IS_CONFIG_NONZERO() to
return the right thing when the config is not defined rather than a
build error, with the limitation that it can't be used on preprocessor
context.
The trick here is that macro names can't start with a number or dash, so
we stringify the argument and check that the first char is a number != 0
(or starting with a dash to cover negative numbers). Except for -O0
builds the strings are all eliminated.
Taking CONFIG_DRM_I915_REQUEST_TIMEOUT in
drivers/gpu/drm/i915/gem/i915_gem_context.c as example, we have the
following output of the preprocessor:
old:
if (((2) != 0) &&
new:
if (( ("2"[0] > '0' && "2"[0] < '9') || "2"[0] == '-' ) &&
New one looks worse, but is also eliminated from the object:
$ size drivers/gpu/drm/i915/gem/i915_gem_context.o.*
textdata bss dec hex filename
520211070 232 53323d04b
drivers/gpu/drm/i915/gem/i915_gem_context.o.new
520211070 232 53323d04b
drivers/gpu/drm/i915/gem/i915_gem_context.o.old
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/i915_utils.h | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_utils.h
b/drivers/gpu/drm/i915/i915_utils.h
index 02bbfa4d68d3..436ce612c46a 100644
--- a/drivers/gpu/drm/i915/i915_utils.h
+++ b/drivers/gpu/drm/i915/i915_utils.h
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
#include
#include
@@ -469,6 +470,9 @@ static inline bool timer_expired(const struct timer_list *t)
*
* Returns 0 if @config is 0, 1 if set to any value.
*/
-#define IS_CONFIG_NONZERO(config) ((config) != 0)
+#define IS_CONFIG_NONZERO(config) (
\
+ (__stringify_1(config)[0] > '0' && __stringify_1(config)[0] < '9') ||
\
+ __stringify_1(config)[0] == '-'
\
+)
Quite clever trick, but I see two issues:
- gcc < 8.1 treats expressions with string indices (ex. "abc"[0]) as
non-constant expressions, so they cannot be used everywhere, for example
in global variable initializations,
ugh, that would kill the idea - having the strings and additional
runtime checks would not be good. Maybe if we check with
__builtin_constant_p() and do the simpler expansion if it's not
constant?
- it does not work with hex (0x1) or octal values (01)
indeed, but I guess that would be fixable by checking (s[0] == '0' && s[1] ==
'\0')?
However, it seems kconfig doesn't support setting int options to hex or
octal.
If I try an hex value in menuconfig it says "You have made an invalid entry."
If I try editing .config or setting via scripts/config --set-val, it
just gets reset when trying to generate include/generated/autoconf.h
Lucas De Marchi
It is probably OK for private macro, but it can hurt in kconfig.h,
especially the 2nd issue
Regards
Andrzej
#endif /* !__I915_UTILS_H */
[PATCH v1 2/2] drm/tegra: dc: rgb: Allow changing PLLD rate on Tegra30+
Asus Transformer TF700T is a Tegra30 tablet device which uses RGB->DSI
bridge that requires a precise clock rate in order to operate properly.
Tegra30 has a dedicated PLL for each display controller, hence the PLL
rate can be changed freely. Allow PLL rate changes on Tegra30+ for RGB
output. Configure the clock rate before display controller is enabled
since DC itself may be running off this PLL and it's not okay to change
the rate of the active PLL that doesn't support dynamic frequency
switching since hardware will hang.
Tested-by: Maxim Schwalm #TF700T
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/tegra/dc.c | 27
drivers/gpu/drm/tegra/dc.h | 1 +
drivers/gpu/drm/tegra/rgb.c | 49 +++--
3 files changed, 65 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
index a582ce28b632..de4a7cb271ce 100644
--- a/drivers/gpu/drm/tegra/dc.c
+++ b/drivers/gpu/drm/tegra/dc.c
@@ -1762,10 +1762,9 @@ int tegra_dc_state_setup_clock(struct tegra_dc *dc,
return 0;
}
-static void tegra_dc_commit_state(struct tegra_dc *dc,
- struct tegra_dc_state *state)
+static void tegra_dc_set_clock_rate(struct tegra_dc *dc,
+ struct tegra_dc_state *state)
{
- u32 value;
int err;
err = clk_set_parent(dc->clk, state->clk);
@@ -1796,11 +1795,6 @@ static void tegra_dc_commit_state(struct tegra_dc *dc,
DRM_DEBUG_KMS("rate: %lu, div: %u\n", clk_get_rate(dc->clk),
state->div);
DRM_DEBUG_KMS("pclk: %lu\n", state->pclk);
-
- if (!dc->soc->has_nvdisplay) {
- value = SHIFT_CLK_DIVIDER(state->div) | PIXEL_CLK_DIVIDER_PCD1;
- tegra_dc_writel(dc, value, DC_DISP_DISP_CLOCK_CONTROL);
- }
}
static void tegra_dc_stop(struct tegra_dc *dc)
@@ -2002,6 +1996,9 @@ static void tegra_crtc_atomic_enable(struct drm_crtc
*crtc,
u32 value;
int err;
+ /* apply PLL changes */
+ tegra_dc_set_clock_rate(dc, crtc_state);
+
err = host1x_client_resume(>client);
if (err < 0) {
dev_err(dc->dev, "failed to resume: %d\n", err);
@@ -2076,8 +2073,11 @@ static void tegra_crtc_atomic_enable(struct drm_crtc
*crtc,
else
tegra_dc_writel(dc, 0, DC_DISP_BORDER_COLOR);
- /* apply PLL and pixel clock changes */
- tegra_dc_commit_state(dc, crtc_state);
+ /* apply pixel clock changes */
+ if (!dc->soc->has_nvdisplay) {
+ value = SHIFT_CLK_DIVIDER(crtc_state->div) |
PIXEL_CLK_DIVIDER_PCD1;
+ tegra_dc_writel(dc, value, DC_DISP_DISP_CLOCK_CONTROL);
+ }
/* program display mode */
tegra_dc_set_timings(dc, mode);
@@ -2691,6 +2691,7 @@ static const struct tegra_dc_soc_info tegra20_dc_soc_info
= {
.has_win_b_vfilter_mem_client = true,
.has_win_c_without_vert_filter = true,
.plane_tiled_memory_bandwidth_x2 = false,
+ .has_pll_d2_out0 = false,
};
static const struct tegra_dc_soc_info tegra30_dc_soc_info = {
@@ -2713,6 +2714,7 @@ static const struct tegra_dc_soc_info tegra30_dc_soc_info
= {
.has_win_b_vfilter_mem_client = true,
.has_win_c_without_vert_filter = false,
.plane_tiled_memory_bandwidth_x2 = true,
+ .has_pll_d2_out0 = true,
};
static const struct tegra_dc_soc_info tegra114_dc_soc_info = {
@@ -2735,6 +2737,7 @@ static const struct tegra_dc_soc_info
tegra114_dc_soc_info = {
.has_win_b_vfilter_mem_client = false,
.has_win_c_without_vert_filter = false,
.plane_tiled_memory_bandwidth_x2 = true,
+ .has_pll_d2_out0 = true,
};
static const struct tegra_dc_soc_info tegra124_dc_soc_info = {
@@ -2757,6 +2760,7 @@ static const struct tegra_dc_soc_info
tegra124_dc_soc_info = {
.has_win_b_vfilter_mem_client = false,
.has_win_c_without_vert_filter = false,
.plane_tiled_memory_bandwidth_x2 = false,
+ .has_pll_d2_out0 = true,
};
static const struct tegra_dc_soc_info tegra210_dc_soc_info = {
@@ -2779,6 +2783,7 @@ static const struct tegra_dc_soc_info
tegra210_dc_soc_info = {
.has_win_b_vfilter_mem_client = false,
.has_win_c_without_vert_filter = false,
.plane_tiled_memory_bandwidth_x2 = false,
+ .has_pll_d2_out0 = true,
};
static const struct tegra_windowgroup_soc tegra186_dc_wgrps[] = {
@@ -2829,6 +2834,7 @@ static const struct tegra_dc_soc_info
tegra186_dc_soc_info = {
.wgrps = tegra186_dc_wgrps,
.num_wgrps = ARRAY_SIZE(tegra186_dc_wgrps),
.plane_tiled_memory_bandwidth_x2 = false,
+ .has_pll_d2_out0 = false,
};
static const struct tegra_windowgroup_soc tegra194_dc_wgrps[] = {
@@ -2879,6 +2885,7 @@ static const struct tegra_dc_soc_info
tegra194_dc_soc_info = {
.wgrps = tegra194_dc_wgrps,
.num_wgrps =
[PATCH v1 1/2] drm/tegra: dc: rgb: Move PCLK shifter programming to CRTC
Asus TF700T tablet uses TC358768 DPI->DSI bridge that sits between Tegra's
DPI output and display panel input. Bridge requires to have stable PCLK
output before RGB encoder is enabled because it uses PCLK by itself to
clock internal logic and bridge is programmed before Tegra's encoder is
enabled. Hence the PCLK clock shifter must be programmed when CRTC is
enabled, otherwise clock is unstable and bridge hangs because of it.
Move the shifter programming from RGB encoder into CRTC.
Tested-by: Maxim Schwalm #TF700T
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/tegra/dc.c | 6 ++
drivers/gpu/drm/tegra/rgb.c | 4
2 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
index a29d64f87563..a582ce28b632 100644
--- a/drivers/gpu/drm/tegra/dc.c
+++ b/drivers/gpu/drm/tegra/dc.c
@@ -2107,6 +2107,12 @@ static void tegra_crtc_atomic_enable(struct drm_crtc
*crtc,
tegra_dc_writel(dc, value, DC_COM_RG_UNDERFLOW);
}
+ if (dc->rgb) {
+ /* XXX: parameterize? */
+ value = SC0_H_QUALIFIER_NONE | SC1_H_QUALIFIER_NONE;
+ tegra_dc_writel(dc, value, DC_DISP_SHIFT_CLOCK_OPTIONS);
+ }
+
tegra_dc_commit(dc);
drm_crtc_vblank_on(crtc);
diff --git a/drivers/gpu/drm/tegra/rgb.c b/drivers/gpu/drm/tegra/rgb.c
index 606c78a2b988..933e14e4609f 100644
--- a/drivers/gpu/drm/tegra/rgb.c
+++ b/drivers/gpu/drm/tegra/rgb.c
@@ -116,10 +116,6 @@ static void tegra_rgb_encoder_enable(struct drm_encoder
*encoder)
DISP_ORDER_RED_BLUE;
tegra_dc_writel(rgb->dc, value, DC_DISP_DISP_INTERFACE_CONTROL);
- /* XXX: parameterize? */
- value = SC0_H_QUALIFIER_NONE | SC1_H_QUALIFIER_NONE;
- tegra_dc_writel(rgb->dc, value, DC_DISP_SHIFT_CLOCK_OPTIONS);
-
tegra_dc_commit(rgb->dc);
}
--
2.32.0
[PATCH v1 0/2] NVIDIA Tegra display driver improvements
Asus Transformer TF700T tablet requires couple minor changes to the display driver in order to light up display panel, here they are. Dmitry Osipenko (2): drm/tegra: dc: rgb: Move PCLK shifter programming to CRTC drm/tegra: dc: rgb: Allow changing PLLD rate on Tegra30+ drivers/gpu/drm/tegra/dc.c | 33 --- drivers/gpu/drm/tegra/dc.h | 1 + drivers/gpu/drm/tegra/rgb.c | 53 - 3 files changed, 71 insertions(+), 16 deletions(-) -- 2.32.0
Re: [PATCH v4 00/24] drm/bridge: Make panel and bridge probe order consistent
Hi Maxime,
(CC'ing Kieran)
On Fri, Sep 10, 2021 at 12:11:54PM +0200, Maxime Ripard wrote:
> Hi,
>
> We've encountered an issue with the RaspberryPi DSI panel that prevented the
> whole display driver from probing.
>
> The issue is described in detail in the commit 7213246a803f ("drm/vc4: dsi:
> Only register our component once a DSI device is attached"), but the basic
> idea
> is that since the panel is probed through i2c, there's no synchronization
> between its probe and the registration of the MIPI-DSI host it's attached to.
>
> We initially moved the component framework registration to the MIPI-DSI Host
> attach hook to make sure we register our component only when we have a DSI
> device attached to our MIPI-DSI host, and then use lookup our DSI device in
> our
> bind hook.
>
> However, all the DSI bridges controlled through i2c are only registering their
> associated DSI device in their bridge attach hook, meaning with our change
> above, we never got that far, and therefore ended up in the same situation
> than
> the one we were trying to fix for panels.
>
> The best practice to avoid those issues is to register its functions only
> after
> all its dependencies are live. We also shouldn't wait any longer than we
> should
> to play nice with the other components that are waiting for us, so in our case
> that would mean moving the DSI device registration to the bridge probe.
>
> I also had a look at all the DSI hosts, and it seems that exynos, kirin and
> msm
> would be affected by this and wouldn't probe anymore after those changes.
> Exynos and kirin seems to be simple enough for a mechanical change (that still
> requires to be tested), but the changes in msm seemed to be far more important
> and I wasn't confortable doing them.
>
> Let me know what you think,
I've tested this series on my RPi CM4-based board, and there's a clear
improvement: the sn65dsi83 now probes successfully !
The downside is that I can now look at a panel that desperately refuses
to display anything. That's a separate issue, but it prevents me from
telling whether this series introduces regressions :-S I'll try to debug
that separately.
Also, Kieran, would you be able to test this with the SN65DSI86 ?
> ---
>
> Changes from v3:
> - Converted exynos and kirin
> - Converted all the affected bridge drivers
> - Reworded the documentation a bit
>
> Changes from v2:
> - Changed the approach as suggested by Andrzej, and aligned the bridge on
> the
> panel this time.
> - Fixed some typos
>
> Changes from v1:
> - Change the name of drm_of_get_next function to drm_of_get_bridge
> - Mention the revert of 87154ff86bf6 and squash the two patches that were
> reverting that commit
> - Add some documentation
> - Make drm_panel_attach and _detach succeed when no callback is there
>
> Maxime Ripard (24):
> drm/bridge: Add documentation sections
> drm/bridge: Document the probe issue with MIPI-DSI bridges
> drm/mipi-dsi: Create devm device registration
> drm/mipi-dsi: Create devm device attachment
> drm/bridge: adv7533: Switch to devm MIPI-DSI helpers
> drm/bridge: adv7511: Register and attach our DSI device at probe
> drm/bridge: anx7625: Switch to devm MIPI-DSI helpers
> drm/bridge: anx7625: Register and attach our DSI device at probe
> drm/bridge: lt8912b: Switch to devm MIPI-DSI helpers
> drm/bridge: lt8912b: Register and attach our DSI device at probe
> drm/bridge: lt9611: Switch to devm MIPI-DSI helpers
> drm/bridge: lt9611: Register and attach our DSI device at probe
> drm/bridge: lt9611uxc: Switch to devm MIPI-DSI helpers
> drm/bridge: lt9611uxc: Register and attach our DSI device at probe
> drm/bridge: ps8640: Switch to devm MIPI-DSI helpers
> drm/bridge: ps8640: Register and attach our DSI device at probe
> drm/bridge: sn65dsi83: Switch to devm MIPI-DSI helpers
> drm/bridge: sn65dsi83: Register and attach our DSI device at probe
> drm/bridge: sn65dsi86: Switch to devm MIPI-DSI helpers
> drm/bridge: sn65dsi86: Register and attach our DSI device at probe
> drm/bridge: tc358775: Switch to devm MIPI-DSI helpers
> drm/bridge: tc358775: Register and attach our DSI device at probe
> drm/kirin: dsi: Adjust probe order
> drm/exynos: dsi: Adjust probe order
>
> Documentation/gpu/drm-kms-helpers.rst| 12 +++
> drivers/gpu/drm/bridge/adv7511/adv7511.h | 1 -
> drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 15 ++-
> drivers/gpu/drm/bridge/adv7511/adv7533.c | 20 +---
> drivers/gpu/drm/bridge/analogix/anx7625.c| 40
> drivers/gpu/drm/bridge/lontium-lt8912b.c | 31 ++
> drivers/gpu/drm/bridge/lontium-lt9611.c | 62 +---
> drivers/gpu/drm/bridge/lontium-lt9611uxc.c | 65 +---
> drivers/gpu/drm/bridge/parade-ps8640.c | 101 ++-
> drivers/gpu/drm/bridge/tc358775.c| 50 +
> drivers/gpu/drm/bridge/ti-sn65dsi83.c| 86
>
Re: [PATCH v4 00/24] drm/bridge: Make panel and bridge probe order consistent
On Wed, Sep 29, 2021 at 2:32 PM John Stultz wrote: > On Wed, Sep 29, 2021 at 2:27 PM John Stultz wrote: > > On Fri, Sep 10, 2021 at 3:12 AM Maxime Ripard wrote: > > > The best practice to avoid those issues is to register its functions only > > > after > > > all its dependencies are live. We also shouldn't wait any longer than we > > > should > > > to play nice with the other components that are waiting for us, so in our > > > case > > > that would mean moving the DSI device registration to the bridge probe. > > > > > > I also had a look at all the DSI hosts, and it seems that exynos, kirin > > > and msm > > > would be affected by this and wouldn't probe anymore after those changes. > > > Exynos and kirin seems to be simple enough for a mechanical change (that > > > still > > > requires to be tested), but the changes in msm seemed to be far more > > > important > > > and I wasn't confortable doing them. > > > > > > Hey Maxime, > > Sorry for taking so long to get to this, but now that plumbers is > > over I've had a chance to check it out on kirin > > > > Rob Clark pointed me to his branch with some fixups here: > > > > https://gitlab.freedesktop.org/robclark/msm/-/commits/for-mripard/bridge-rework > > > > But trying to boot hikey with that, I see the following loop indefinitely: > > [4.632132] adv7511 2-0039: supply avdd not found, using dummy regulator > > [4.638961] adv7511 2-0039: supply dvdd not found, using dummy regulator > > [4.645741] adv7511 2-0039: supply pvdd not found, using dummy regulator > > [4.652483] adv7511 2-0039: supply a2vdd not found, using dummy regulator > > [4.659342] adv7511 2-0039: supply v3p3 not found, using dummy regulator > > [4.666086] adv7511 2-0039: supply v1p2 not found, using dummy regulator > > [4.681898] adv7511 2-0039: failed to find dsi host > > I just realized Rob's tree is missing the kirin patch. My apologies! > I'll retest and let you know. Ok, just retested including the kirin patch and unfortunately I'm still seeing the same thing. :( Will dig a bit and let you know when I find more. thanks -john
[PATCH] drm/brdige: analogix_dp: Grab runtime PM reference for DP-AUX
If the display is not enable()d, then we aren't holding a runtime PM
reference here. Thus, it's easy to accidentally cause a hang, if user
space is poking around at /dev/drm_dp_aux0 at the "wrong" time.
Let's get the panel and PM state right before trying to talk AUX.
Fixes: 0d97ad03f422 ("drm/bridge: analogix_dp: Remove duplicated code")
Cc:
Cc: Tomeu Vizoso
Signed-off-by: Brian Norris
---
.../gpu/drm/bridge/analogix/analogix_dp_core.c | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index b7d2e4449cfa..a1b553904b85 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -1632,8 +1632,23 @@ static ssize_t analogix_dpaux_transfer(struct drm_dp_aux
*aux,
struct drm_dp_aux_msg *msg)
{
struct analogix_dp_device *dp = to_dp(aux);
+ int ret, ret2;
- return analogix_dp_transfer(dp, msg);
+ ret = analogix_dp_prepare_panel(dp, true, false);
+ if (ret) {
+ DRM_DEV_ERROR(dp->dev, "Failed to prepare panel (%d)\n", ret);
+ return ret;
+ }
+
+ pm_runtime_get_sync(dp->dev);
+ ret = analogix_dp_transfer(dp, msg);
+ pm_runtime_put(dp->dev);
+
+ ret2 = analogix_dp_prepare_panel(dp, false, false);
+ if (ret2)
+ DRM_DEV_ERROR(dp->dev, "Failed to unprepare panel (%d)\n",
ret2);
+
+ return ret;
}
struct analogix_dp_device *
--
2.33.0.685.g46640cef36-goog
Re: [PATCH v4 00/24] drm/bridge: Make panel and bridge probe order consistent
On Wed, Sep 29, 2021 at 2:27 PM John Stultz wrote:
>
> On Fri, Sep 10, 2021 at 3:12 AM Maxime Ripard wrote:
> >
> > We've encountered an issue with the RaspberryPi DSI panel that prevented the
> > whole display driver from probing.
> >
> > The issue is described in detail in the commit 7213246a803f ("drm/vc4: dsi:
> > Only register our component once a DSI device is attached"), but the basic
> > idea
> > is that since the panel is probed through i2c, there's no synchronization
> > between its probe and the registration of the MIPI-DSI host it's attached
> > to.
> >
> > We initially moved the component framework registration to the MIPI-DSI Host
> > attach hook to make sure we register our component only when we have a DSI
> > device attached to our MIPI-DSI host, and then use lookup our DSI device in
> > our
> > bind hook.
> >
> > However, all the DSI bridges controlled through i2c are only registering
> > their
> > associated DSI device in their bridge attach hook, meaning with our change
> > above, we never got that far, and therefore ended up in the same situation
> > than
> > the one we were trying to fix for panels.
> >
> > The best practice to avoid those issues is to register its functions only
> > after
> > all its dependencies are live. We also shouldn't wait any longer than we
> > should
> > to play nice with the other components that are waiting for us, so in our
> > case
> > that would mean moving the DSI device registration to the bridge probe.
> >
> > I also had a look at all the DSI hosts, and it seems that exynos, kirin and
> > msm
> > would be affected by this and wouldn't probe anymore after those changes.
> > Exynos and kirin seems to be simple enough for a mechanical change (that
> > still
> > requires to be tested), but the changes in msm seemed to be far more
> > important
> > and I wasn't confortable doing them.
>
>
> Hey Maxime,
> Sorry for taking so long to get to this, but now that plumbers is
> over I've had a chance to check it out on kirin
>
> Rob Clark pointed me to his branch with some fixups here:
>
> https://gitlab.freedesktop.org/robclark/msm/-/commits/for-mripard/bridge-rework
>
> But trying to boot hikey with that, I see the following loop indefinitely:
> [4.632132] adv7511 2-0039: supply avdd not found, using dummy regulator
> [4.638961] adv7511 2-0039: supply dvdd not found, using dummy regulator
> [4.645741] adv7511 2-0039: supply pvdd not found, using dummy regulator
> [4.652483] adv7511 2-0039: supply a2vdd not found, using dummy regulator
> [4.659342] adv7511 2-0039: supply v3p3 not found, using dummy regulator
> [4.666086] adv7511 2-0039: supply v1p2 not found, using dummy regulator
> [4.681898] adv7511 2-0039: failed to find dsi host
I just realized Rob's tree is missing the kirin patch. My apologies!
I'll retest and let you know.
thanks
-john
Re: [PATCH v4 00/24] drm/bridge: Make panel and bridge probe order consistent
On Fri, Sep 10, 2021 at 3:12 AM Maxime Ripard wrote:
>
> We've encountered an issue with the RaspberryPi DSI panel that prevented the
> whole display driver from probing.
>
> The issue is described in detail in the commit 7213246a803f ("drm/vc4: dsi:
> Only register our component once a DSI device is attached"), but the basic
> idea
> is that since the panel is probed through i2c, there's no synchronization
> between its probe and the registration of the MIPI-DSI host it's attached to.
>
> We initially moved the component framework registration to the MIPI-DSI Host
> attach hook to make sure we register our component only when we have a DSI
> device attached to our MIPI-DSI host, and then use lookup our DSI device in
> our
> bind hook.
>
> However, all the DSI bridges controlled through i2c are only registering their
> associated DSI device in their bridge attach hook, meaning with our change
> above, we never got that far, and therefore ended up in the same situation
> than
> the one we were trying to fix for panels.
>
> The best practice to avoid those issues is to register its functions only
> after
> all its dependencies are live. We also shouldn't wait any longer than we
> should
> to play nice with the other components that are waiting for us, so in our case
> that would mean moving the DSI device registration to the bridge probe.
>
> I also had a look at all the DSI hosts, and it seems that exynos, kirin and
> msm
> would be affected by this and wouldn't probe anymore after those changes.
> Exynos and kirin seems to be simple enough for a mechanical change (that still
> requires to be tested), but the changes in msm seemed to be far more important
> and I wasn't confortable doing them.
Hey Maxime,
Sorry for taking so long to get to this, but now that plumbers is
over I've had a chance to check it out on kirin
Rob Clark pointed me to his branch with some fixups here:
https://gitlab.freedesktop.org/robclark/msm/-/commits/for-mripard/bridge-rework
But trying to boot hikey with that, I see the following loop indefinitely:
[4.632132] adv7511 2-0039: supply avdd not found, using dummy regulator
[4.638961] adv7511 2-0039: supply dvdd not found, using dummy regulator
[4.645741] adv7511 2-0039: supply pvdd not found, using dummy regulator
[4.652483] adv7511 2-0039: supply a2vdd not found, using dummy regulator
[4.659342] adv7511 2-0039: supply v3p3 not found, using dummy regulator
[4.666086] adv7511 2-0039: supply v1p2 not found, using dummy regulator
[4.681898] adv7511 2-0039: failed to find dsi host
[4.688836] adv7511 2-0039: supply avdd not found, using dummy regulator
[4.695724] adv7511 2-0039: supply dvdd not found, using dummy regulator
[4.702583] adv7511 2-0039: supply pvdd not found, using dummy regulator
[4.709369] adv7511 2-0039: supply a2vdd not found, using dummy regulator
[4.716232] adv7511 2-0039: supply v3p3 not found, using dummy regulator
[4.722972] adv7511 2-0039: supply v1p2 not found, using dummy regulator
[4.738720] adv7511 2-0039: failed to find dsi host
I'll have to dig a bit to figure out what's going wrong, but wanted to
give you the heads up that there seems to be a problem
thanks
-john
Re: [PATCH v2 2/3] drm/i915/utils: do not depend on config being defined
W dniu 29.09.2021 o 20:33, Lucas De Marchi pisze:
> Like the IS_ENABLED() counterpart, we can make IS_CONFIG_NONZERO() to
> return the right thing when the config is not defined rather than a
> build error, with the limitation that it can't be used on preprocessor
> context.
>
> The trick here is that macro names can't start with a number or dash, so
> we stringify the argument and check that the first char is a number != 0
> (or starting with a dash to cover negative numbers). Except for -O0
> builds the strings are all eliminated.
>
> Taking CONFIG_DRM_I915_REQUEST_TIMEOUT in
> drivers/gpu/drm/i915/gem/i915_gem_context.c as example, we have the
> following output of the preprocessor:
>
> old:
> if (((2) != 0) &&
> new:
> if (( ("2"[0] > '0' && "2"[0] < '9') || "2"[0] == '-' ) &&
>
> New one looks worse, but is also eliminated from the object:
>
> $ size drivers/gpu/drm/i915/gem/i915_gem_context.o.*
> textdata bss dec hex filename
>520211070 232 53323d04b
> drivers/gpu/drm/i915/gem/i915_gem_context.o.new
>520211070 232 53323d04b
> drivers/gpu/drm/i915/gem/i915_gem_context.o.old
>
> Signed-off-by: Lucas De Marchi
> ---
> drivers/gpu/drm/i915/i915_utils.h | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_utils.h
> b/drivers/gpu/drm/i915/i915_utils.h
> index 02bbfa4d68d3..436ce612c46a 100644
> --- a/drivers/gpu/drm/i915/i915_utils.h
> +++ b/drivers/gpu/drm/i915/i915_utils.h
> @@ -28,6 +28,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
>
> @@ -469,6 +470,9 @@ static inline bool timer_expired(const struct timer_list
> *t)
>*
>* Returns 0 if @config is 0, 1 if set to any value.
>*/
> -#define IS_CONFIG_NONZERO(config) ((config) != 0)
> +#define IS_CONFIG_NONZERO(config) (
> \
> + (__stringify_1(config)[0] > '0' && __stringify_1(config)[0] < '9') ||
> \
> + __stringify_1(config)[0] == '-'
> \
> +)
Quite clever trick, but I see two issues:
- gcc < 8.1 treats expressions with string indices (ex. "abc"[0]) as
non-constant expressions, so they cannot be used everywhere, for example
in global variable initializations,
- it does not work with hex (0x1) or octal values (01)
It is probably OK for private macro, but it can hurt in kconfig.h,
especially the 2nd issue
Regards
Andrzej
>
> #endif /* !__I915_UTILS_H */
kmemleak report: 5.15.0-rc3: nouveau_fence_new
Hello, With 5.15.0-rc3 on my ppc64 (PowerMac G5) I am seeing kmemleak reports. They are always 96 bytes and with the same stacktrace. unreferenced object 0xc00011d2a7e0 (size 96): comm "X", pid 1743, jiffies 4295010075 (age 5457.040s) hex dump (first 32 bytes): c0 00 00 00 0b 9f f0 00 c0 00 3d 00 00 b0 85 90 ..=. 00 00 00 a9 77 41 30 23 c0 00 00 00 08 db b7 c8 wA0# backtrace: [<6f102108>] .nouveau_fence_new+0x4c/0x120 [nouveau] [<395e0a83>] .nouveau_bo_move+0x4f0/0x870 [nouveau] [] .ttm_bo_handle_move_mem+0xb4/0x1e0 [ttm] [ ] .ttm_bo_validate+0x144/0x230 [ttm] [ ] .nouveau_bo_validate+0x70/0xc0 [nouveau] [ ] .nouveau_gem_ioctl_pushbuf+0x6e0/0x1a90 [nouveau] [<7b7c5c38>] .drm_ioctl_kernel+0x104/0x180 [drm] [<0af76e30>] .drm_ioctl+0x244/0x490 [drm] [ ] .nouveau_drm_ioctl+0x78/0x140 [nouveau] [<263274a7>] .__se_sys_ioctl+0xfc/0x160 [<88c39f3d>] .system_call_exception+0x178/0x2a0 [<0cfdf34f>] system_call_common+0xec/0x250 If I decode this stacktrace using decode_stacktrace.sh so that the line numbers can be seen, I get the following: .nouveau_fence_new+0x4c/0x120 [nouveau] linux-5.15-rc3/include/linux/slab.h:591 linux-5.15-rc3/include/linux/slab.h:721 linux-5.15-rc3/drivers/gpu/drm/nouveau/nouveau_fence.c:424 .nouveau_bo_move+0x4f0/0x870 [nouveau] linux-5.15-rc3/drivers/gpu/drm/nouveau/nouveau_bo.c:821 linux-5.15-rc3/drivers/gpu/drm/nouveau/nouveau_bo.c:1032 .ttm_bo_handle_move_mem+0xb4/0x1e0 [ttm] linux-5.15-rc3/drivers/gpu/drm/ttm/ttm_bo.c:197 .ttm_bo_validate+0x144/0x230 [ttm] linux-5.15-rc3/drivers/gpu/drm/ttm/ttm_bo.c:904 linux-5.15-rc3/drivers/gpu/drm/ttm/ttm_bo.c:981 .nouveau_bo_validate+0x70/0xc0 [nouveau] linux-5.15-rc3/drivers/gpu/drm/nouveau/nouveau_bo.c:647 .nouveau_gem_ioctl_pushbuf+0x6e0/0x1a90 [nouveau] linux-5.15-rc3/drivers/gpu/drm/nouveau/nouveau_gem.c:548 linux-5.15-rc3/drivers/gpu/drm/nouveau/nouveau_gem.c:605 linux-5.15-rc3/drivers/gpu/drm/nouveau/nouveau_gem.c:799 .drm_ioctl_kernel+0x104/0x180 [drm] linux-5.15-rc3/drivers/gpu/drm/drm_ioctl.c:795 .drm_ioctl+0x244/0x490 [drm] linux-5.15-rc3/include/linux/thread_info.h:185 linux-5.15-rc3/include/linux/thread_info.h:218 linux-5.15-rc3/include/linux/uaccess.h:199 linux-5.15-rc3/drivers/gpu/drm/drm_ioctl.c:899 .nouveau_drm_ioctl+0x78/0x140 [nouveau] linux-5.15-rc3/drivers/gpu/drm/nouveau/nouveau_drm.c:1163 .__se_sys_ioctl+0xfc/0x160 linux-5.15-rc3/fs/ioctl.c:51 linux-5.15-rc3/fs/ioctl.c:874 linux-5.15-rc3/fs/ioctl.c:860 .system_call_exception+0x178/0x2a0 .system_call_exception linux-5.15-rc3/arch/powerpc/kernel/interrupt.c:233 system_call_common+0xec/0x250 linux-5.15-rc3/arch/powerpc/kernel/interrupt_64.S:314 Here are all enabled DRM and NOUVEAU configs in my kernel: CONFIG_DRM=m CONFIG_DRM_KMS_HELPER=m CONFIG_DRM_FBDEV_EMULATION=y CONFIG_DRM_FBDEV_OVERALLOC=100 CONFIG_DRM_TTM=m CONFIG_DRM_TTM_HELPER=m CONFIG_DRM_NOUVEAU=m CONFIG_NOUVEAU_DEBUG=5 CONFIG_NOUVEAU_DEBUG_DEFAULT=3 CONFIG_DRM_NOUVEAU_BACKLIGHT=y CONFIG_DRM_PANEL=y CONFIG_DRM_BRIDGE=y CONFIG_DRM_PANEL_BRIDGE=y CONFIG_DRM_PANEL_ORIENTATION_QUIRKS=m And lspci output: :f0:10.0 VGA compatible controller: NVIDIA Corporation NV34 [GeForce FX 5200 Ultra] (rev a1) I have been running 5.12 on my machine without these reports. So it might be something that showed up in 5.13 or 5.14 as well. I do not know if this is a good channel for reporting this, so please let me know if I should report it somewhere else. Also let me know if you need any additional information from me. John Ogness
Re: [Intel-gfx] [PATCH 25/27] drm/i915/guc: Handle errors in multi-lrc requests
On Wed, Sep 29, 2021 at 01:44:10PM -0700, John Harrison wrote:
> On 8/20/2021 15:44, Matthew Brost wrote:
> > If an error occurs in the front end when multi-lrc requests are getting
> > generated we need to skip these in the backend but we still need to
> > emit the breadcrumbs seqno. An issues arrises because with multi-lrc
> arrises -> arises
>
Yep.
> > breadcrumbs there is a handshake between the parent and children to make
> > forwad progress. If all the requests are not present this handshake
> forwad -> forward
>
Yep.
> > doesn't work. To work around this, if multi-lrc request has an error we
> > skip the handshake but still emit the breadcrumbs seqno.
> >
> > Signed-off-by: Matthew Brost
> > ---
> > .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 61 ++-
> > 1 file changed, 58 insertions(+), 3 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 2ef38557b0f0..61e737fd1eee 100644
> > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > @@ -3546,8 +3546,8 @@ static int
> > emit_bb_start_child_no_preempt_mid_batch(struct i915_request *rq,
> > }
> > static u32 *
> > -emit_fini_breadcrumb_parent_no_preempt_mid_batch(struct i915_request *rq,
> > -u32 *cs)
> > +__emit_fini_breadcrumb_parent_no_preempt_mid_batch(struct i915_request *rq,
> > + u32 *cs)
> > {
> > struct intel_context *ce = rq->context;
> > u8 i;
> > @@ -3575,6 +3575,41 @@
> > emit_fini_breadcrumb_parent_no_preempt_mid_batch(struct i915_request *rq,
> > get_children_go_addr(ce),
> > 0);
> > + return cs;
> > +}
> > +
> > +/*
> > + * If this true, a submission of multi-lrc requests had an error and the
> > + * requests need to be skipped. The front end (execuf IOCTL) should've
> > called
> > + * i915_request_skip which squashes the BB but we still need to emit the
> > fini
> > + * breadrcrumbs seqno write. At this point we don't know how many of the
> > + * requests in the multi-lrc submission were generated so we can't do the
> > + * handshake between the parent and children (e.g. if 4 requests should be
> > + * generated but 2nd hit an error only 1 would be seen by the GuC backend).
> > + * Simply skip the handshake, but still emit the breadcrumbd seqno, if an
> > error
> > + * has occurred on any of the requests in submission / relationship.
> > + */
> > +static inline bool skip_handshake(struct i915_request *rq)
> > +{
> > + return test_bit(I915_FENCE_FLAG_SKIP_PARALLEL, >fence.flags);
> > +}
> > +
> > +static u32 *
> > +emit_fini_breadcrumb_parent_no_preempt_mid_batch(struct i915_request *rq,
> > +u32 *cs)
> > +{
> > + struct intel_context *ce = rq->context;
> > +
> > + GEM_BUG_ON(!intel_context_is_parent(ce));
> > +
> > + if (unlikely(skip_handshake(rq))) {
> > + memset(cs, 0, sizeof(u32) *
> > + (ce->engine->emit_fini_breadcrumb_dw - 6));
> > + cs += ce->engine->emit_fini_breadcrumb_dw - 6;
> Why -6? There are 12 words about to be written. Indeed the value of
> emit_..._dw is '12 + 4*num_children'. This should only be skipping over the
> 4*children, right? As it stands, it will skip all but the last six words,
> then write an extra twelve words and thus overflow the reservation by six.
> Unless I am totally confused?
>
Let me decode the length:
'Wait on children' (in __emit_fini_breadcrumb_parent_no_preempt_mid_batch) = 4
* num_children
'Turn on preemption' (in __emit_fini_breadcrumb_parent_no_preempt_mid_batch) = 2
'Tell children go' (in __emit_fini_breadcrumb_parent_no_preempt_mid_batch) = 4
'Emit fini breadcrumb' (in emit_fini_breadcrumb_child_no_preempt_mid_batch) = 4
'User interrupt' (in emit_fini_breadcrumb_child_no_preempt_mid_batch) = 2
So for a total (emit_fini_breadcrumb_dw) we have '12 + 4 * num_children'
We want skip everything in __emit_fini_breadcrumb_parent_no_preempt_mid_batch,
so that is
'6 + 4 * num_children' or 'emit_fini_breadcrumb_dw - 6'
Make sense?
> I assume there is some reason why the amount of data written must exactly
> match the space reserved? It's a while since I've looked at the ring buffer
> code!
>
I think it because the ring space is reserved at request creation time
but the fini breadcrumbs are not written until submission time.
> Seems like it would be clearer to not split the semaphore writes out but
> have them right next to the skip code that is meant to replicate them but
> with no-ops.
>
I guess that works too, I personally like the way it is but if you
insist I can change it.
> > + } else {
> > + cs = __emit_fini_breadcrumb_parent_no_preempt_mid_batch(rq, cs);
> > + }
> > +
> > /* Emit fini breadcrumb */
> > cs =
Re: [Intel-gfx] [PATCH 25/27] drm/i915/guc: Handle errors in multi-lrc requests
On 8/20/2021 15:44, Matthew Brost wrote:
If an error occurs in the front end when multi-lrc requests are getting
generated we need to skip these in the backend but we still need to
emit the breadcrumbs seqno. An issues arrises because with multi-lrc
arrises -> arises
breadcrumbs there is a handshake between the parent and children to make
forwad progress. If all the requests are not present this handshake
forwad -> forward
doesn't work. To work around this, if multi-lrc request has an error we
skip the handshake but still emit the breadcrumbs seqno.
Signed-off-by: Matthew Brost
---
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 61 ++-
1 file changed, 58 insertions(+), 3 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 2ef38557b0f0..61e737fd1eee 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -3546,8 +3546,8 @@ static int
emit_bb_start_child_no_preempt_mid_batch(struct i915_request *rq,
}
static u32 *
-emit_fini_breadcrumb_parent_no_preempt_mid_batch(struct i915_request *rq,
-u32 *cs)
+__emit_fini_breadcrumb_parent_no_preempt_mid_batch(struct i915_request *rq,
+ u32 *cs)
{
struct intel_context *ce = rq->context;
u8 i;
@@ -3575,6 +3575,41 @@ emit_fini_breadcrumb_parent_no_preempt_mid_batch(struct
i915_request *rq,
get_children_go_addr(ce),
0);
+ return cs;
+}
+
+/*
+ * If this true, a submission of multi-lrc requests had an error and the
+ * requests need to be skipped. The front end (execuf IOCTL) should've called
+ * i915_request_skip which squashes the BB but we still need to emit the fini
+ * breadrcrumbs seqno write. At this point we don't know how many of the
+ * requests in the multi-lrc submission were generated so we can't do the
+ * handshake between the parent and children (e.g. if 4 requests should be
+ * generated but 2nd hit an error only 1 would be seen by the GuC backend).
+ * Simply skip the handshake, but still emit the breadcrumbd seqno, if an error
+ * has occurred on any of the requests in submission / relationship.
+ */
+static inline bool skip_handshake(struct i915_request *rq)
+{
+ return test_bit(I915_FENCE_FLAG_SKIP_PARALLEL, >fence.flags);
+}
+
+static u32 *
+emit_fini_breadcrumb_parent_no_preempt_mid_batch(struct i915_request *rq,
+u32 *cs)
+{
+ struct intel_context *ce = rq->context;
+
+ GEM_BUG_ON(!intel_context_is_parent(ce));
+
+ if (unlikely(skip_handshake(rq))) {
+ memset(cs, 0, sizeof(u32) *
+ (ce->engine->emit_fini_breadcrumb_dw - 6));
+ cs += ce->engine->emit_fini_breadcrumb_dw - 6;
Why -6? There are 12 words about to be written. Indeed the value of
emit_..._dw is '12 + 4*num_children'. This should only be skipping over
the 4*children, right? As it stands, it will skip all but the last six
words, then write an extra twelve words and thus overflow the
reservation by six. Unless I am totally confused?
I assume there is some reason why the amount of data written must
exactly match the space reserved? It's a while since I've looked at the
ring buffer code!
Seems like it would be clearer to not split the semaphore writes out but
have them right next to the skip code that is meant to replicate them
but with no-ops.
+ } else {
+ cs = __emit_fini_breadcrumb_parent_no_preempt_mid_batch(rq, cs);
+ }
+
/* Emit fini breadcrumb */
cs = gen8_emit_ggtt_write(cs,
rq->fence.seqno,
@@ -3591,7 +3626,8 @@ emit_fini_breadcrumb_parent_no_preempt_mid_batch(struct
i915_request *rq,
}
static u32 *
-emit_fini_breadcrumb_child_no_preempt_mid_batch(struct i915_request *rq, u32
*cs)
+__emit_fini_breadcrumb_child_no_preempt_mid_batch(struct i915_request *rq,
+ u32 *cs)
{
struct intel_context *ce = rq->context;
@@ -3617,6 +3653,25 @@ emit_fini_breadcrumb_child_no_preempt_mid_batch(struct i915_request *rq, u32 *cs
*cs++ = get_children_go_addr(ce->parent);
*cs++ = 0;
+ return cs;
+}
+
+static u32 *
+emit_fini_breadcrumb_child_no_preempt_mid_batch(struct i915_request *rq,
+ u32 *cs)
+{
+ struct intel_context *ce = rq->context;
+
+ GEM_BUG_ON(!intel_context_is_child(ce));
+
+ if (unlikely(skip_handshake(rq))) {
+ memset(cs, 0, sizeof(u32) *
+ (ce->engine->emit_fini_breadcrumb_dw - 6));
+ cs += ce->engine->emit_fini_breadcrumb_dw - 6;
+ } else {
+ cs =
[PATCH 2/2] amd/amdgpu_dm: Verify Gamma and Degamma LUT sizes using DRM Core check
From: Mark Yacoub
[Why]
drm_atomic_helper_check_crtc now verifies both legacy and non-legacy LUT
sizes. There is no need to check it within amdgpu_dm_atomic_check.
[How]
Remove the local call to verify LUT sizes and use DRM Core function
instead.
Tested on ChromeOS Zork.
Signed-off-by: Mark Yacoub
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 07adac1a8c42b..96a1d006b777e 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -10683,6 +10683,10 @@ static int amdgpu_dm_atomic_check(struct drm_device
*dev,
}
}
#endif
+ ret = drm_atomic_helper_check_crtc(state);
+ if (ret)
+ return ret;
+
for_each_oldnew_crtc_in_state(state, crtc, old_crtc_state,
new_crtc_state, i) {
dm_old_crtc_state = to_dm_crtc_state(old_crtc_state);
@@ -10692,10 +10696,6 @@ static int amdgpu_dm_atomic_check(struct drm_device
*dev,
dm_old_crtc_state->dsc_force_changed == false)
continue;
- ret = amdgpu_dm_verify_lut_sizes(new_crtc_state);
- if (ret)
- goto fail;
-
if (!new_crtc_state->enable)
continue;
--
2.33.0.685.g46640cef36-goog
[PATCH 1/2] drm: Add Gamma and Degamma LUT sizes props to drm_crtc to validate.
From: Mark Yacoub
[Why]
1. drm_atomic_helper_check doesn't check for the LUT sizes of either Gamma
or Degamma props in the new CRTC state, allowing any invalid size to
be passed on.
2. Each driver has its own LUT size, which could also be different for
legacy users.
[How]
1. Create |degamma_lut_size| and |gamma_lut_size| to save the LUT sizes
assigned by the driver when it's initializing its color and CTM
management.
2. Create drm_atomic_helper_check_crtc which is called by
drm_atomic_helper_check to check the LUT sizes saved in drm_crtc that
they match the sizes in the new CRTC state.
Fixes: igt@kms_color@pipe-A-invalid-gamma-lut-sizes on MTK
Tested on Zork(amdgpu) and Jacuzzi(mediatek)
Signed-off-by: Mark Yacoub
---
drivers/gpu/drm/drm_atomic_helper.c | 56 +
drivers/gpu/drm/drm_color_mgmt.c| 2 ++
include/drm/drm_atomic_helper.h | 1 +
include/drm/drm_crtc.h | 11 ++
4 files changed, 70 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 2c0c6ec928200..265b9747250d1 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -930,6 +930,58 @@ drm_atomic_helper_check_planes(struct drm_device *dev,
}
EXPORT_SYMBOL(drm_atomic_helper_check_planes);
+/**
+ * drm_atomic_helper_check_planes - validate state object for CRTC changes
+ * @state: the driver state object
+ *
+ * Check the CRTC state object such as the Gamma/Degamma LUT sizes if the new
+ * state holds them.
+ *
+ * RETURNS:
+ * Zero for success or -errno
+ */
+int drm_atomic_helper_check_crtc(struct drm_atomic_state *state)
+{
+ struct drm_crtc *crtc;
+ struct drm_crtc_state *new_crtc_state;
+ int i;
+
+ for_each_new_crtc_in_state (state, crtc, new_crtc_state, i) {
+ if (new_crtc_state->gamma_lut) {
+ uint64_t supported_lut_size = crtc->gamma_lut_size;
+ uint32_t supported_legacy_lut_size = crtc->gamma_size;
+ uint32_t new_state_lut_size =
+ drm_color_lut_size(new_crtc_state->gamma_lut);
+
+ if (new_state_lut_size != supported_lut_size &&
+ new_state_lut_size != supported_legacy_lut_size) {
+ DRM_DEBUG_DRIVER(
+ "Invalid Gamma LUT size. Should be %u
(or %u for legacy) but got %u.\n",
+ supported_lut_size,
+ supported_legacy_lut_size,
+ new_state_lut_size);
+ return -EINVAL;
+ }
+ }
+
+ if (new_crtc_state->degamma_lut) {
+ uint32_t new_state_lut_size =
+ drm_color_lut_size(new_crtc_state->degamma_lut);
+ uint64_t supported_lut_size = crtc->degamma_lut_size;
+
+ if (new_state_lut_size != supported_lut_size) {
+ DRM_DEBUG_DRIVER(
+ "Invalid Degamma LUT size. Should be %u
but got %u.\n",
+ supported_lut_size, new_state_lut_size);
+ return -EINVAL;
+ }
+ }
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_atomic_helper_check_crtc);
+
/**
* drm_atomic_helper_check - validate state object
* @dev: DRM device
@@ -975,6 +1027,10 @@ int drm_atomic_helper_check(struct drm_device *dev,
if (ret)
return ret;
+ ret = drm_atomic_helper_check_crtc(state);
+ if (ret)
+ return ret;
+
if (state->legacy_cursor_update)
state->async_update = !drm_atomic_helper_async_check(dev,
state);
diff --git a/drivers/gpu/drm/drm_color_mgmt.c b/drivers/gpu/drm/drm_color_mgmt.c
index bb14f488c8f6c..72a1b628e7cdd 100644
--- a/drivers/gpu/drm/drm_color_mgmt.c
+++ b/drivers/gpu/drm/drm_color_mgmt.c
@@ -166,6 +166,7 @@ void drm_crtc_enable_color_mgmt(struct drm_crtc *crtc,
struct drm_mode_config *config = >mode_config;
if (degamma_lut_size) {
+ crtc->degamma_lut_size = degamma_lut_size;
drm_object_attach_property(>base,
config->degamma_lut_property, 0);
drm_object_attach_property(>base,
@@ -178,6 +179,7 @@ void drm_crtc_enable_color_mgmt(struct drm_crtc *crtc,
config->ctm_property, 0);
if (gamma_lut_size) {
+ crtc->gamma_lut_size = gamma_lut_size;
drm_object_attach_property(>base,
config->gamma_lut_property, 0);
drm_object_attach_property(>base,
diff --git a/include/drm/drm_atomic_helper.h
[PATCH v3 4/6] drm/gud: Add GUD_PIXEL_FORMAT_R8
Add support for 8-bit greyscale format.
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/gud/gud_drv.c | 2 ++
drivers/gpu/drm/gud/gud_internal.h | 4
drivers/gpu/drm/gud/gud_pipe.c | 2 ++
include/drm/gud.h | 4 ++--
4 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/gud/gud_drv.c b/drivers/gpu/drm/gud/gud_drv.c
index eb4e08846da4..a8d76c76e868 100644
--- a/drivers/gpu/drm/gud/gud_drv.c
+++ b/drivers/gpu/drm/gud/gud_drv.c
@@ -523,6 +523,8 @@ static int gud_probe(struct usb_interface *intf, const
struct usb_device_id *id)
switch (format) {
case GUD_DRM_FORMAT_R1:
fallthrough;
+ case DRM_FORMAT_R8:
+ fallthrough;
case GUD_DRM_FORMAT_XRGB:
if (!xrgb_emulation_format)
xrgb_emulation_format = info;
diff --git a/drivers/gpu/drm/gud/gud_internal.h
b/drivers/gpu/drm/gud/gud_internal.h
index 2a388e27d5d7..8499e713dbbc 100644
--- a/drivers/gpu/drm/gud/gud_internal.h
+++ b/drivers/gpu/drm/gud/gud_internal.h
@@ -80,6 +80,8 @@ static inline u8 gud_from_fourcc(u32 fourcc)
switch (fourcc) {
case GUD_DRM_FORMAT_R1:
return GUD_PIXEL_FORMAT_R1;
+ case DRM_FORMAT_R8:
+ return GUD_PIXEL_FORMAT_R8;
case GUD_DRM_FORMAT_XRGB:
return GUD_PIXEL_FORMAT_XRGB;
case DRM_FORMAT_RGB565:
@@ -98,6 +100,8 @@ static inline u32 gud_to_fourcc(u8 format)
switch (format) {
case GUD_PIXEL_FORMAT_R1:
return GUD_DRM_FORMAT_R1;
+ case GUD_PIXEL_FORMAT_R8:
+ return DRM_FORMAT_R8;
case GUD_PIXEL_FORMAT_XRGB:
return GUD_DRM_FORMAT_XRGB;
case GUD_PIXEL_FORMAT_RGB565:
diff --git a/drivers/gpu/drm/gud/gud_pipe.c b/drivers/gpu/drm/gud/gud_pipe.c
index b9b0e435ea0f..be4f95b2d59c 100644
--- a/drivers/gpu/drm/gud/gud_pipe.c
+++ b/drivers/gpu/drm/gud/gud_pipe.c
@@ -189,6 +189,8 @@ static int gud_prep_flush(struct gud_device *gdrm, struct
drm_framebuffer *fb,
ret = -ENOMEM;
goto end_cpu_access;
}
+ } else if (format->format == DRM_FORMAT_R8) {
+ drm_fb_xrgb_to_gray8(buf, vaddr, fb, rect);
} else if (format->format == DRM_FORMAT_RGB565) {
drm_fb_xrgb_to_rgb565(buf, vaddr, fb, rect,
gud_is_big_endian());
} else {
diff --git a/include/drm/gud.h b/include/drm/gud.h
index 0b46b54fe56e..1dc781009e62 100644
--- a/include/drm/gud.h
+++ b/include/drm/gud.h
@@ -246,8 +246,8 @@ struct gud_state_req {
/* Get supported pixel formats as a byte array of GUD_PIXEL_FORMAT_* */
#define GUD_REQ_GET_FORMATS0x40
#define GUD_FORMATS_MAX_NUM 32
- /* R1 is a 1-bit monochrome transfer format presented to userspace as
XRGB */
- #define GUD_PIXEL_FORMAT_R1 0x01
+ #define GUD_PIXEL_FORMAT_R1 0x01 /* 1-bit monochrome */
+ #define GUD_PIXEL_FORMAT_R8 0x08 /* 8-bit greyscale */
#define GUD_PIXEL_FORMAT_XRGB0x20
#define GUD_PIXEL_FORMAT_RGB565 0x40
#define GUD_PIXEL_FORMAT_XRGB0x80
--
2.32.0
[PATCH v3 5/6] drm/gud: Add GUD_PIXEL_FORMAT_RGB332
Add support for the RGB332 pixel format.
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/gud/gud_drv.c | 2 ++
drivers/gpu/drm/gud/gud_internal.h | 4
drivers/gpu/drm/gud/gud_pipe.c | 2 ++
include/drm/gud.h | 1 +
4 files changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/gud/gud_drv.c b/drivers/gpu/drm/gud/gud_drv.c
index a8d76c76e868..e571ad10a12b 100644
--- a/drivers/gpu/drm/gud/gud_drv.c
+++ b/drivers/gpu/drm/gud/gud_drv.c
@@ -526,6 +526,8 @@ static int gud_probe(struct usb_interface *intf, const
struct usb_device_id *id)
case DRM_FORMAT_R8:
fallthrough;
case GUD_DRM_FORMAT_XRGB:
+ fallthrough;
+ case DRM_FORMAT_RGB332:
if (!xrgb_emulation_format)
xrgb_emulation_format = info;
break;
diff --git a/drivers/gpu/drm/gud/gud_internal.h
b/drivers/gpu/drm/gud/gud_internal.h
index 8499e713dbbc..249e02d1f5ed 100644
--- a/drivers/gpu/drm/gud/gud_internal.h
+++ b/drivers/gpu/drm/gud/gud_internal.h
@@ -84,6 +84,8 @@ static inline u8 gud_from_fourcc(u32 fourcc)
return GUD_PIXEL_FORMAT_R8;
case GUD_DRM_FORMAT_XRGB:
return GUD_PIXEL_FORMAT_XRGB;
+ case DRM_FORMAT_RGB332:
+ return GUD_PIXEL_FORMAT_RGB332;
case DRM_FORMAT_RGB565:
return GUD_PIXEL_FORMAT_RGB565;
case DRM_FORMAT_XRGB:
@@ -104,6 +106,8 @@ static inline u32 gud_to_fourcc(u8 format)
return DRM_FORMAT_R8;
case GUD_PIXEL_FORMAT_XRGB:
return GUD_DRM_FORMAT_XRGB;
+ case GUD_PIXEL_FORMAT_RGB332:
+ return DRM_FORMAT_RGB332;
case GUD_PIXEL_FORMAT_RGB565:
return DRM_FORMAT_RGB565;
case GUD_PIXEL_FORMAT_XRGB:
diff --git a/drivers/gpu/drm/gud/gud_pipe.c b/drivers/gpu/drm/gud/gud_pipe.c
index be4f95b2d59c..868a0b8a1f3e 100644
--- a/drivers/gpu/drm/gud/gud_pipe.c
+++ b/drivers/gpu/drm/gud/gud_pipe.c
@@ -191,6 +191,8 @@ static int gud_prep_flush(struct gud_device *gdrm, struct
drm_framebuffer *fb,
}
} else if (format->format == DRM_FORMAT_R8) {
drm_fb_xrgb_to_gray8(buf, vaddr, fb, rect);
+ } else if (format->format == DRM_FORMAT_RGB332) {
+ drm_fb_xrgb_to_rgb332(buf, vaddr, fb, rect);
} else if (format->format == DRM_FORMAT_RGB565) {
drm_fb_xrgb_to_rgb565(buf, vaddr, fb, rect,
gud_is_big_endian());
} else {
diff --git a/include/drm/gud.h b/include/drm/gud.h
index 1dc781009e62..4118dce2fcec 100644
--- a/include/drm/gud.h
+++ b/include/drm/gud.h
@@ -249,6 +249,7 @@ struct gud_state_req {
#define GUD_PIXEL_FORMAT_R1 0x01 /* 1-bit monochrome */
#define GUD_PIXEL_FORMAT_R8 0x08 /* 8-bit greyscale */
#define GUD_PIXEL_FORMAT_XRGB0x20
+ #define GUD_PIXEL_FORMAT_RGB332 0x30
#define GUD_PIXEL_FORMAT_RGB565 0x40
#define GUD_PIXEL_FORMAT_XRGB0x80
#define GUD_PIXEL_FORMAT_ARGB0x81
--
2.32.0
[PATCH v3 6/6] drm/gud: Add GUD_PIXEL_FORMAT_RGB888
Add support for the RGB888 pixel format.
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/gud/gud_drv.c | 2 ++
drivers/gpu/drm/gud/gud_internal.h | 4
drivers/gpu/drm/gud/gud_pipe.c | 2 ++
include/drm/gud.h | 1 +
4 files changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/gud/gud_drv.c b/drivers/gpu/drm/gud/gud_drv.c
index e571ad10a12b..3f9d4b9a1e3d 100644
--- a/drivers/gpu/drm/gud/gud_drv.c
+++ b/drivers/gpu/drm/gud/gud_drv.c
@@ -528,6 +528,8 @@ static int gud_probe(struct usb_interface *intf, const
struct usb_device_id *id)
case GUD_DRM_FORMAT_XRGB:
fallthrough;
case DRM_FORMAT_RGB332:
+ fallthrough;
+ case DRM_FORMAT_RGB888:
if (!xrgb_emulation_format)
xrgb_emulation_format = info;
break;
diff --git a/drivers/gpu/drm/gud/gud_internal.h
b/drivers/gpu/drm/gud/gud_internal.h
index 249e02d1f5ed..e351a1f1420d 100644
--- a/drivers/gpu/drm/gud/gud_internal.h
+++ b/drivers/gpu/drm/gud/gud_internal.h
@@ -88,6 +88,8 @@ static inline u8 gud_from_fourcc(u32 fourcc)
return GUD_PIXEL_FORMAT_RGB332;
case DRM_FORMAT_RGB565:
return GUD_PIXEL_FORMAT_RGB565;
+ case DRM_FORMAT_RGB888:
+ return GUD_PIXEL_FORMAT_RGB888;
case DRM_FORMAT_XRGB:
return GUD_PIXEL_FORMAT_XRGB;
case DRM_FORMAT_ARGB:
@@ -110,6 +112,8 @@ static inline u32 gud_to_fourcc(u8 format)
return DRM_FORMAT_RGB332;
case GUD_PIXEL_FORMAT_RGB565:
return DRM_FORMAT_RGB565;
+ case GUD_PIXEL_FORMAT_RGB888:
+ return DRM_FORMAT_RGB888;
case GUD_PIXEL_FORMAT_XRGB:
return DRM_FORMAT_XRGB;
case GUD_PIXEL_FORMAT_ARGB:
diff --git a/drivers/gpu/drm/gud/gud_pipe.c b/drivers/gpu/drm/gud/gud_pipe.c
index 868a0b8a1f3e..daf75c178c2b 100644
--- a/drivers/gpu/drm/gud/gud_pipe.c
+++ b/drivers/gpu/drm/gud/gud_pipe.c
@@ -195,6 +195,8 @@ static int gud_prep_flush(struct gud_device *gdrm, struct
drm_framebuffer *fb,
drm_fb_xrgb_to_rgb332(buf, vaddr, fb, rect);
} else if (format->format == DRM_FORMAT_RGB565) {
drm_fb_xrgb_to_rgb565(buf, vaddr, fb, rect,
gud_is_big_endian());
+ } else if (format->format == DRM_FORMAT_RGB888) {
+ drm_fb_xrgb_to_rgb888(buf, vaddr, fb, rect);
} else {
len = gud_xrgb_to_color(buf, format, vaddr, fb,
rect);
}
diff --git a/include/drm/gud.h b/include/drm/gud.h
index 4118dce2fcec..c52a8ba4ae4e 100644
--- a/include/drm/gud.h
+++ b/include/drm/gud.h
@@ -251,6 +251,7 @@ struct gud_state_req {
#define GUD_PIXEL_FORMAT_XRGB0x20
#define GUD_PIXEL_FORMAT_RGB332 0x30
#define GUD_PIXEL_FORMAT_RGB565 0x40
+ #define GUD_PIXEL_FORMAT_RGB888 0x50
#define GUD_PIXEL_FORMAT_XRGB0x80
#define GUD_PIXEL_FORMAT_ARGB0x81
--
2.32.0
[PATCH v3 2/6] drm/format-helper: Add drm_fb_xrgb8888_to_rgb332()
Add XRGB emulation support for devices that can only do RGB332.
v2:
- Support Big Endian (Daniel)
Cc: Thomas Zimmermann
Reviewed-by: Daniel Vetter
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/drm_format_helper.c | 50 +
include/drm/drm_format_helper.h | 2 ++
2 files changed, 52 insertions(+)
diff --git a/drivers/gpu/drm/drm_format_helper.c
b/drivers/gpu/drm/drm_format_helper.c
index 5231104b1498..dab4f382d469 100644
--- a/drivers/gpu/drm/drm_format_helper.c
+++ b/drivers/gpu/drm/drm_format_helper.c
@@ -135,6 +135,56 @@ void drm_fb_swab(void *dst, void *src, struct
drm_framebuffer *fb,
}
EXPORT_SYMBOL(drm_fb_swab);
+static void drm_fb_xrgb_to_rgb332_line(u8 *dbuf, __le32 *sbuf, unsigned
int pixels)
+{
+ unsigned int x;
+ u32 pix;
+
+ for (x = 0; x < pixels; x++) {
+ pix = le32_to_cpu(sbuf[x]);
+ dbuf[x] = ((pix & 0x00e0) >> 16) |
+ ((pix & 0xe000) >> 11) |
+ ((pix & 0x00c0) >> 6);
+ }
+}
+
+/**
+ * drm_fb_xrgb_to_rgb332 - Convert XRGB to RGB332 clip buffer
+ * @dst: RGB332 destination buffer
+ * @src: XRGB source buffer
+ * @fb: DRM framebuffer
+ * @clip: Clip rectangle area to copy
+ *
+ * Drivers can use this function for RGB332 devices that don't natively
support XRGB.
+ *
+ * This function does not apply clipping on dst, i.e. the destination is a
small buffer
+ * containing the clip rect only.
+ */
+void drm_fb_xrgb_to_rgb332(void *dst, void *src, struct drm_framebuffer
*fb,
+ struct drm_rect *clip)
+{
+ size_t width = drm_rect_width(clip);
+ size_t src_len = width * sizeof(u32);
+ unsigned int y;
+ void *sbuf;
+
+ /* Use a buffer to speed up access on buffers with uncached read
mapping (i.e. WC) */
+ sbuf = kmalloc(src_len, GFP_KERNEL);
+ if (!sbuf)
+ return;
+
+ src += clip_offset(clip, fb->pitches[0], sizeof(u32));
+ for (y = 0; y < drm_rect_height(clip); y++) {
+ memcpy(sbuf, src, src_len);
+ drm_fb_xrgb_to_rgb332_line(dst, sbuf, width);
+ src += fb->pitches[0];
+ dst += width;
+ }
+
+ kfree(sbuf);
+}
+EXPORT_SYMBOL(drm_fb_xrgb_to_rgb332);
+
static void drm_fb_xrgb_to_rgb565_line(u16 *dbuf, u32 *sbuf,
unsigned int pixels,
bool swab)
diff --git a/include/drm/drm_format_helper.h b/include/drm/drm_format_helper.h
index 4e0258a61311..d0809aff5cf8 100644
--- a/include/drm/drm_format_helper.h
+++ b/include/drm/drm_format_helper.h
@@ -16,6 +16,8 @@ void drm_fb_memcpy_dstclip(void __iomem *dst, unsigned int
dst_pitch, void *vadd
struct drm_rect *clip);
void drm_fb_swab(void *dst, void *src, struct drm_framebuffer *fb,
struct drm_rect *clip, bool cached);
+void drm_fb_xrgb_to_rgb332(void *dst, void *vaddr, struct drm_framebuffer
*fb,
+ struct drm_rect *clip);
void drm_fb_xrgb_to_rgb565(void *dst, void *vaddr,
struct drm_framebuffer *fb,
struct drm_rect *clip, bool swab);
--
2.32.0
[PATCH v3 0/6] drm/gud: Add some more pixel formats
Hi, I'd appreciate if someone could review the 3 small driver patches. Changes since version 2: - Drop the patch adding module parameter 'xrgb'. Both Daniel and Thomas had some comments that eventually led me to to drop this for now. Noralf. Noralf Trønnes (6): drm/fourcc: Add R8 to drm_format_info drm/format-helper: Add drm_fb_xrgb_to_rgb332() drm/format-helper: Add drm_fb_xrgb_to_rgb888() drm/gud: Add GUD_PIXEL_FORMAT_R8 drm/gud: Add GUD_PIXEL_FORMAT_RGB332 drm/gud: Add GUD_PIXEL_FORMAT_RGB888 drivers/gpu/drm/drm_format_helper.c | 88 + drivers/gpu/drm/drm_fourcc.c| 1 + drivers/gpu/drm/gud/gud_drv.c | 6 ++ drivers/gpu/drm/gud/gud_internal.h | 12 drivers/gpu/drm/gud/gud_pipe.c | 6 ++ include/drm/drm_format_helper.h | 4 ++ include/drm/gud.h | 6 +- 7 files changed, 121 insertions(+), 2 deletions(-) -- 2.32.0
[PATCH v3 1/6] drm/fourcc: Add R8 to drm_format_info
Add an entry in drm_format_info for the existing format DRM_FORMAT_R8.
Reviewed-by: Daniel Vetter
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/drm_fourcc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index eda832f9200d..783844bfecc1 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -133,6 +133,7 @@ const struct drm_format_info *__drm_format_info(u32 format)
{
static const struct drm_format_info formats[] = {
{ .format = DRM_FORMAT_C8, .depth = 8,
.num_planes = 1, .cpp = { 1, 0, 0 }, .hsub = 1, .vsub = 1 },
+ { .format = DRM_FORMAT_R8, .depth = 8,
.num_planes = 1, .cpp = { 1, 0, 0 }, .hsub = 1, .vsub = 1 },
{ .format = DRM_FORMAT_RGB332, .depth = 8,
.num_planes = 1, .cpp = { 1, 0, 0 }, .hsub = 1, .vsub = 1 },
{ .format = DRM_FORMAT_BGR233, .depth = 8,
.num_planes = 1, .cpp = { 1, 0, 0 }, .hsub = 1, .vsub = 1 },
{ .format = DRM_FORMAT_XRGB,.depth = 0,
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1 },
--
2.32.0
[PATCH v3 3/6] drm/format-helper: Add drm_fb_xrgb8888_to_rgb888()
Add XRGB emulation support for devices that can only do RGB888.
Cc: Thomas Zimmermann
Reviewed-by: Daniel Vetter
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/drm_format_helper.c | 38 +
include/drm/drm_format_helper.h | 2 ++
2 files changed, 40 insertions(+)
diff --git a/drivers/gpu/drm/drm_format_helper.c
b/drivers/gpu/drm/drm_format_helper.c
index dab4f382d469..69fde60e36b3 100644
--- a/drivers/gpu/drm/drm_format_helper.c
+++ b/drivers/gpu/drm/drm_format_helper.c
@@ -300,6 +300,44 @@ static void drm_fb_xrgb_to_rgb888_line(u8 *dbuf, u32
*sbuf,
}
}
+/**
+ * drm_fb_xrgb_to_rgb888 - Convert XRGB to RGB888 clip buffer
+ * @dst: RGB888 destination buffer
+ * @src: XRGB source buffer
+ * @fb: DRM framebuffer
+ * @clip: Clip rectangle area to copy
+ *
+ * Drivers can use this function for RGB888 devices that don't natively
+ * support XRGB.
+ *
+ * This function does not apply clipping on dst, i.e. the destination
+ * is a small buffer containing the clip rect only.
+ */
+void drm_fb_xrgb_to_rgb888(void *dst, void *src, struct drm_framebuffer
*fb,
+ struct drm_rect *clip)
+{
+ size_t width = drm_rect_width(clip);
+ size_t src_len = width * sizeof(u32);
+ unsigned int y;
+ void *sbuf;
+
+ /* Use a buffer to speed up access on buffers with uncached read
mapping (i.e. WC) */
+ sbuf = kmalloc(src_len, GFP_KERNEL);
+ if (!sbuf)
+ return;
+
+ src += clip_offset(clip, fb->pitches[0], sizeof(u32));
+ for (y = 0; y < drm_rect_height(clip); y++) {
+ memcpy(sbuf, src, src_len);
+ drm_fb_xrgb_to_rgb888_line(dst, sbuf, width);
+ src += fb->pitches[0];
+ dst += width * 3;
+ }
+
+ kfree(sbuf);
+}
+EXPORT_SYMBOL(drm_fb_xrgb_to_rgb888);
+
/**
* drm_fb_xrgb_to_rgb888_dstclip - Convert XRGB to RGB888 clip buffer
* @dst: RGB565 destination buffer (iomem)
diff --git a/include/drm/drm_format_helper.h b/include/drm/drm_format_helper.h
index d0809aff5cf8..e86925cf07b9 100644
--- a/include/drm/drm_format_helper.h
+++ b/include/drm/drm_format_helper.h
@@ -24,6 +24,8 @@ void drm_fb_xrgb_to_rgb565(void *dst, void *vaddr,
void drm_fb_xrgb_to_rgb565_dstclip(void __iomem *dst, unsigned int
dst_pitch,
void *vaddr, struct drm_framebuffer *fb,
struct drm_rect *clip, bool swab);
+void drm_fb_xrgb_to_rgb888(void *dst, void *src, struct drm_framebuffer
*fb,
+ struct drm_rect *clip);
void drm_fb_xrgb_to_rgb888_dstclip(void __iomem *dst, unsigned int
dst_pitch,
void *vaddr, struct drm_framebuffer *fb,
struct drm_rect *clip);
--
2.32.0
Re: refactor the i915 GVT support
On Wed, Sep 29, 2021 at 06:27:16PM +, Wang, Zhi A wrote: > On 9/28/21 3:05 PM, Jason Gunthorpe wrote: > > On Tue, Sep 28, 2021 at 02:35:06PM +, Wang, Zhi A wrote: > > > >> Yes. I was thinking of the possibility of putting off some work later so > >> that we don't need to make a lot of changes. GVT-g needs to take a > >> snapshot of GPU registers as the initial virtual states for other vGPUs, > >> which requires the initialization happens at a certain early time of > >> initialization of i915. I was thinking maybe we can take other patches > >> from Christoph like "de-virtualize*" except this one because currently > >> we have to maintain a TEST-ONLY patch on our tree to prevent i915 built > >> as kernel module. > > How about just capture these registers in the main module/device and > > not try so hard to isolate it to the gvt stuff? > > Hi Jason: > > Thanks for the idea. I am not sure i915 guys would take this idea since > that it's only for GVT-g, i915 doesn't use this at all. We need to take > a snapshot of both PCI configuration space and MMIO registers before > i915 driver starts to touch the HW. Given the code is already linked into i915 I don't see there is much to object to here. It can remain conditional on the kernel parameter as today. As a general philosophy this would all be much less strange if the mdev .ko is truely optional. It should be cleanly seperate from its base device and never request_module'd.. In this case auxiliary device might be a good option, have i915 create one and the mdev module be loaded against it. In the mean time is there some shortcut to get this series to move ahead? Is patch 4 essential to the rest of the series? A really awful hack would be to push the pci_driver_register into a WQ so that the request_module is guarenteed to not be part of the module_init callchain. > Also I was thinking if moving gvt into kvmgt.ko is the right direction. > It seems the module loading system in kernel is not designed for "module > A loading module B, which needs symbols from module A, in the > initialization path of module A". Of course not, that is a circular module dependency, it should not be that way. The SW layers need to be clean and orderly - meaning the i915 module needs to have the minimal amount of code to support the mdev module. Jason
[PATCH v2 2/3] drm/i915/utils: do not depend on config being defined
Like the IS_ENABLED() counterpart, we can make IS_CONFIG_NONZERO() to
return the right thing when the config is not defined rather than a
build error, with the limitation that it can't be used on preprocessor
context.
The trick here is that macro names can't start with a number or dash, so
we stringify the argument and check that the first char is a number != 0
(or starting with a dash to cover negative numbers). Except for -O0
builds the strings are all eliminated.
Taking CONFIG_DRM_I915_REQUEST_TIMEOUT in
drivers/gpu/drm/i915/gem/i915_gem_context.c as example, we have the
following output of the preprocessor:
old:
if (((2) != 0) &&
new:
if (( ("2"[0] > '0' && "2"[0] < '9') || "2"[0] == '-' ) &&
New one looks worse, but is also eliminated from the object:
$ size drivers/gpu/drm/i915/gem/i915_gem_context.o.*
textdata bss dec hex filename
520211070 232 53323d04b
drivers/gpu/drm/i915/gem/i915_gem_context.o.new
520211070 232 53323d04b
drivers/gpu/drm/i915/gem/i915_gem_context.o.old
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/i915_utils.h | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_utils.h
b/drivers/gpu/drm/i915/i915_utils.h
index 02bbfa4d68d3..436ce612c46a 100644
--- a/drivers/gpu/drm/i915/i915_utils.h
+++ b/drivers/gpu/drm/i915/i915_utils.h
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
#include
#include
@@ -469,6 +470,9 @@ static inline bool timer_expired(const struct timer_list *t)
*
* Returns 0 if @config is 0, 1 if set to any value.
*/
-#define IS_CONFIG_NONZERO(config) ((config) != 0)
+#define IS_CONFIG_NONZERO(config) (
\
+ (__stringify_1(config)[0] > '0' && __stringify_1(config)[0] < '9') ||
\
+ __stringify_1(config)[0] == '-'
\
+)
#endif /* !__I915_UTILS_H */
--
2.33.0
[PATCH v2 1/3] drm/i915: rename IS_ACTIVE
It took me some time to understand the need for IS_ACTIVE and why we
couldn't use kconfig.h. Rename it to something else that would be more
suitable to include in kconfig.h and shared with other subsystems rather
than maintaining it only in i915.
Name here is pretty open for suggestions, but I think this is slightly
better than "active".
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/gem/i915_gem_context.c| 2 +-
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 2 +-
drivers/gpu/drm/i915/gt/intel_engine.h | 4 ++--
drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c | 2 +-
drivers/gpu/drm/i915/gt/intel_engine_types.h | 2 +-
.../gpu/drm/i915/gt/intel_execlists_submission.c | 2 +-
.../gpu/drm/i915/gt/selftest_engine_heartbeat.c| 4 ++--
drivers/gpu/drm/i915/gt/selftest_execlists.c | 14 +++---
drivers/gpu/drm/i915/i915_config.c | 2 +-
drivers/gpu/drm/i915/i915_request.c| 2 +-
drivers/gpu/drm/i915/i915_utils.h | 2 +-
11 files changed, 19 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 8208fd5b72c3..ff748441a0e2 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -761,7 +761,7 @@ static int intel_context_set_gem(struct intel_context *ce,
intel_engine_has_semaphores(ce->engine))
__set_bit(CONTEXT_USE_SEMAPHORES, >flags);
- if (IS_ACTIVE(CONFIG_DRM_I915_REQUEST_TIMEOUT) &&
+ if (IS_CONFIG_NONZERO(CONFIG_DRM_I915_REQUEST_TIMEOUT) &&
ctx->i915->params.request_timeout_ms) {
unsigned int timeout_ms = ctx->i915->params.request_timeout_ms;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index 5130e8ed9564..9e12c026e59f 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
@@ -395,7 +395,7 @@ static vm_fault_t vm_fault_gtt(struct vm_fault *vmf)
/* Track the mmo associated with the fenced vma */
vma->mmo = mmo;
- if (IS_ACTIVE(CONFIG_DRM_I915_USERFAULT_AUTOSUSPEND))
+ if (IS_CONFIG_NONZERO(CONFIG_DRM_I915_USERFAULT_AUTOSUSPEND))
intel_wakeref_auto(>ggtt.userfault_wakeref,
msecs_to_jiffies_timeout(CONFIG_DRM_I915_USERFAULT_AUTOSUSPEND));
diff --git a/drivers/gpu/drm/i915/gt/intel_engine.h
b/drivers/gpu/drm/i915/gt/intel_engine.h
index 87579affb952..f181c8654cbf 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine.h
@@ -273,7 +273,7 @@ static inline bool intel_engine_uses_guc(const struct
intel_engine_cs *engine)
static inline bool
intel_engine_has_preempt_reset(const struct intel_engine_cs *engine)
{
- if (!IS_ACTIVE(CONFIG_DRM_I915_PREEMPT_TIMEOUT))
+ if (!IS_CONFIG_NONZERO(CONFIG_DRM_I915_PREEMPT_TIMEOUT))
return false;
return intel_engine_has_preemption(engine);
@@ -300,7 +300,7 @@ intel_virtual_engine_has_heartbeat(const struct
intel_engine_cs *engine)
static inline bool
intel_engine_has_heartbeat(const struct intel_engine_cs *engine)
{
- if (!IS_ACTIVE(CONFIG_DRM_I915_HEARTBEAT_INTERVAL))
+ if (!IS_CONFIG_NONZERO(CONFIG_DRM_I915_HEARTBEAT_INTERVAL))
return false;
if (intel_engine_is_virtual(engine))
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
index 74775ae961b2..9b2eb0491c9d 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
@@ -207,7 +207,7 @@ static void heartbeat(struct work_struct *wrk)
void intel_engine_unpark_heartbeat(struct intel_engine_cs *engine)
{
- if (!IS_ACTIVE(CONFIG_DRM_I915_HEARTBEAT_INTERVAL))
+ if (!IS_CONFIG_NONZERO(CONFIG_DRM_I915_HEARTBEAT_INTERVAL))
return;
next_heartbeat(engine);
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h
b/drivers/gpu/drm/i915/gt/intel_engine_types.h
index 5ae1207c363b..938b49e41e48 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
@@ -556,7 +556,7 @@ intel_engine_has_semaphores(const struct intel_engine_cs
*engine)
static inline bool
intel_engine_has_timeslices(const struct intel_engine_cs *engine)
{
- if (!IS_ACTIVE(CONFIG_DRM_I915_TIMESLICE_DURATION))
+ if (!IS_CONFIG_NONZERO(CONFIG_DRM_I915_TIMESLICE_DURATION))
return false;
return engine->flags & I915_ENGINE_HAS_TIMESLICES;
diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
index 7147fe80919e..851dce6bfc6f 100644
--- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
+++
[PATCH v2 3/3] Move IS_CONFIG_NONZERO() to kconfig.h
The check for config value doesn't really belong to i915_utils.h - we
are trying to eliminate that utils helper and share them when possible
with other drivers and subsystems.
Rationale for having such macro is in commit
babaab2f4738 ("drm/i915: Encapsulate kconfig constant values inside boolean
predicates")
whereas later it is improved to not break the build if used with
undefined configs. The caveat is detailed in the documentation: unlike
IS_ENABLED(): it's not preprocessor-only logic so can't be used for
things like `#if IS_CONFIG_NONZERO(...)`
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/i915_utils.h | 17 -
include/linux/kconfig.h | 16 ++--
2 files changed, 14 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_utils.h
b/drivers/gpu/drm/i915/i915_utils.h
index 436ce612c46a..62f189e064a9 100644
--- a/drivers/gpu/drm/i915/i915_utils.h
+++ b/drivers/gpu/drm/i915/i915_utils.h
@@ -28,7 +28,6 @@
#include
#include
#include
-#include
#include
#include
@@ -459,20 +458,4 @@ static inline bool timer_expired(const struct timer_list
*t)
return timer_active(t) && !timer_pending(t);
}
-/*
- * This is a lookalike for IS_ENABLED() that takes a kconfig value,
- * e.g. CONFIG_DRM_I915_SPIN_REQUEST, and evaluates whether it is non-zero
- * i.e. whether the configuration is active. Wrapping up the config inside
- * a boolean context prevents clang and smatch from complaining about potential
- * issues in confusing logical-&& with bitwise-& for constants.
- *
- * Sadly IS_ENABLED() itself does not work with kconfig values.
- *
- * Returns 0 if @config is 0, 1 if set to any value.
- */
-#define IS_CONFIG_NONZERO(config) (
\
- (__stringify_1(config)[0] > '0' && __stringify_1(config)[0] < '9') ||
\
- __stringify_1(config)[0] == '-'
\
-)
-
#endif /* !__I915_UTILS_H */
diff --git a/include/linux/kconfig.h b/include/linux/kconfig.h
index 20d1079e92b4..e84f7c1c8e26 100644
--- a/include/linux/kconfig.h
+++ b/include/linux/kconfig.h
@@ -2,6 +2,7 @@
#ifndef __LINUX_KCONFIG_H
#define __LINUX_KCONFIG_H
+#include
#include
#ifdef CONFIG_CPU_BIG_ENDIAN
@@ -26,8 +27,8 @@
#define or(arg1_or_junk, y)__take_second_arg(arg1_or_junk
1, y)
/*
- * Helper macros to use CONFIG_ options in C/CPP expressions. Note that
- * these only work with boolean and tristate options.
+ * Helper macros to use CONFIG_ options in C/CPP expressions. Note that except
+ * for IS_CONFIG_NONZERO, these only work with boolean and tristate options.
*/
/*
@@ -72,4 +73,15 @@
*/
#define IS_ENABLED(option) __or(IS_BUILTIN(option), IS_MODULE(option))
+/*
+ * This is a lookalike for IS_ENABLED(), but works with int kconfig options
+ * with the caveat that it can't be used on preprocessor checks.
+ *
+ * Returns 0 if @config is 0 or undefined, 1 if set to any value.
+ */
+#define IS_CONFIG_NONZERO(config) (
\
+ (__stringify_1(config)[0] > '0' && __stringify_1(config)[0] < '9') ||
\
+ __stringify_1(config)[0] == '-'
\
+)
+
#endif /* __LINUX_KCONFIG_H */
--
2.33.0
[PATCH v2 0/3] Rename IS_ACTIVE() and move to kconfig.h
As we try to reduce our i915-only helpers, let's try to improve IS_ACTIVE() logic and move to kconfig.h. I'm not 100% happy with the name, but it's the best I could come up with, hopefully a little better than trying to add IS_ACTIVE() to be used broadly. v2: now with Cc/To list fixed up - no changes to the patches. Lucas De Marchi (3): drm/i915: rename IS_ACTIVE drm/i915/utils: do not depend on config being defined Move IS_CONFIG_NONZERO() to kconfig.h drivers/gpu/drm/i915/gem/i915_gem_context.c | 2 +- drivers/gpu/drm/i915/gem/i915_gem_mman.c | 2 +- drivers/gpu/drm/i915/gt/intel_engine.h | 4 ++-- drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c | 2 +- drivers/gpu/drm/i915/gt/intel_engine_types.h | 2 +- .../gpu/drm/i915/gt/intel_execlists_submission.c | 2 +- .../gpu/drm/i915/gt/selftest_engine_heartbeat.c | 4 ++-- drivers/gpu/drm/i915/gt/selftest_execlists.c | 14 +++--- drivers/gpu/drm/i915/i915_config.c | 2 +- drivers/gpu/drm/i915/i915_request.c | 2 +- drivers/gpu/drm/i915/i915_utils.h| 13 - include/linux/kconfig.h | 16 ++-- 12 files changed, 32 insertions(+), 33 deletions(-) -- 2.33.0
Re: [PATCH] [RFC] qcom_scm: hide Kconfig symbol
On Wed, Sep 29, 2021 at 4:46 PM Bjorn Andersson
wrote:
>
> On Wed 29 Sep 05:04 CDT 2021, Arnd Bergmann wrote:
>
> > On Wed, Sep 29, 2021 at 11:51 AM Will Deacon wrote:
> > > On Mon, Sep 27, 2021 at 05:22:13PM +0200, Arnd Bergmann wrote:
> > > >
> > > > diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
> > > > index 124c41adeca1..989c83acbfee 100644
> > > > --- a/drivers/iommu/Kconfig
> > > > +++ b/drivers/iommu/Kconfig
> > > > @@ -308,7 +308,7 @@ config APPLE_DART
> > > > config ARM_SMMU
> > > > tristate "ARM Ltd. System MMU (SMMU) Support"
> > > > depends on ARM64 || ARM || (COMPILE_TEST && !GENERIC_ATOMIC64)
> > > > - depends on QCOM_SCM || !QCOM_SCM #if QCOM_SCM=m this can't be =y
> > > > + select QCOM_SCM
> > > > select IOMMU_API
> > > > select IOMMU_IO_PGTABLE_LPAE
> > > > select ARM_DMA_USE_IOMMU if ARM
> > >
> > > I don't want to get in the way of this patch because I'm also tired of the
> > > randconfig failures caused by QCOM_SCM. However, ARM_SMMU is applicable to
> > > a wide variety of (non-qcom) SoCs and so it seems a shame to require the
> > > QCOM_SCM code to be included for all of those when it's not strictly
> > > needed
> > > at all.
> >
> > Good point, I agree that needs to be fixed. I think this additional
> > change should do the trick:
> >
>
> ARM_SMMU and QCOM_IOMMU are two separate implementations and both uses
> QCOM_SCM. So both of them should select QCOM_SCM.
Right, I figured that out later as well.
> "Unfortunately" the Qualcomm portion of ARM_SMMU is builtin
> unconditionally, so going with something like select QCOM_SCM if
> ARCH_QCOM would still require the stubs in qcom_scm.h.
Yes, sounds good. I also noticed that I still need one hack in there
if I do this:
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
index 55690af1b25d..36c304a8fc9b 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
@@ -427,6 +427,9 @@ struct arm_smmu_device *qcom_smmu_impl_init(struct
arm_smmu_device *smmu)
{
const struct device_node *np = smmu->dev->of_node;
+ if (!IS_ENABLED(CONFIG_QCOM_SCM))
+ return ERR_PTR(-ENXIO);
+
#ifdef CONFIG_ACPI
if (np == NULL) {
/* Match platform for ACPI boot */
Otherwise it still breaks with ARM_SMMU=y and QCOM_SCM=m.
Splitting out the qualcomm portion of the arm_smmu driver using
a separate 'bool' symbol should also work, if you prefer that
and can suggest a name and help text for that symbol. It would
look like
diff --git a/drivers/iommu/arm/arm-smmu/Makefile
b/drivers/iommu/arm/arm-smmu/Makefile
index e240a7bcf310..b0cc01aa20c9 100644
--- a/drivers/iommu/arm/arm-smmu/Makefile
+++ b/drivers/iommu/arm/arm-smmu/Makefile
@@ -1,4 +1,5 @@
# SPDX-License-Identifier: GPL-2.0
obj-$(CONFIG_QCOM_IOMMU) += qcom_iommu.o
obj-$(CONFIG_ARM_SMMU) += arm_smmu.o
-arm_smmu-objs += arm-smmu.o arm-smmu-impl.o arm-smmu-nvidia.o arm-smmu-qcom.o
+arm_smmu-objs += arm-smmu.o arm-smmu-impl.o arm-smmu-nvidia.o
+arm_smmu-$(CONFIG_ARM_SMMU_QCOM) += arm-smmu-qcom.o
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-impl.c
b/drivers/iommu/arm/arm-smmu/arm-smmu-impl.c
index 9f465e146799..2c25cce38060 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu-impl.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu-impl.c
@@ -215,7 +215,8 @@ struct arm_smmu_device *arm_smmu_impl_init(struct
arm_smmu_device *smmu)
of_device_is_compatible(np, "nvidia,tegra186-smmu"))
return nvidia_smmu_impl_init(smmu);
- smmu = qcom_smmu_impl_init(smmu);
+ if (IS_ENABLED(CONFIG_ARM_SMMU_QCOM))
+ smmu = qcom_smmu_impl_init(smmu);
if (of_device_is_compatible(np, "marvell,ap806-smmu-500"))
smmu->impl = _mmu500_impl;
Arnd
Re: refactor the i915 GVT support
On 9/28/21 3:05 PM, Jason Gunthorpe wrote:
> On Tue, Sep 28, 2021 at 02:35:06PM +, Wang, Zhi A wrote:
>
>> Yes. I was thinking of the possibility of putting off some work later so
>> that we don't need to make a lot of changes. GVT-g needs to take a
>> snapshot of GPU registers as the initial virtual states for other vGPUs,
>> which requires the initialization happens at a certain early time of
>> initialization of i915. I was thinking maybe we can take other patches
>> from Christoph like "de-virtualize*" except this one because currently
>> we have to maintain a TEST-ONLY patch on our tree to prevent i915 built
>> as kernel module.
> How about just capture these registers in the main module/device and
> not try so hard to isolate it to the gvt stuff?
Hi Jason:
Thanks for the idea. I am not sure i915 guys would take this idea since
that it's only for GVT-g, i915 doesn't use this at all. We need to take
a snapshot of both PCI configuration space and MMIO registers before
i915 driver starts to touch the HW.
One idea is we capture the registers in intel_gvt.c during the early
initialization and do everything else when i915.ko is fully loaded. But
how about dependence between i915.ko and kvmgt.ko? We cannot do
request_module("kvmgt") in i915.ko.
Maybe Christoph can give more input on this and how we can deal with
this? Before we figure out an solution, we have to pick that patch out
since it blocks our pull request schedule.
Also I was thinking if moving gvt into kvmgt.ko is the right direction.
It seems the module loading system in kernel is not designed for "module
A loading module B, which needs symbols from module A, in the
initialization path of module A".
Thanks,
Zhi.
> Jason
[PATCH 2/3] drm/i915/utils: do not depend on config being defined
Like the IS_ENABLED() counterpart, we can make IS_CONFIG_NONZERO() to
return the right thing when the config is not defined rather than a
build error, with the limitation that it can't be used on preprocessor
context.
The trick here is that macro names can't start with a number or dash, so
we stringify the argument and check that the first char is a number != 0
(or starting with a dash to cover negative numbers). Except for -O0
builds the strings are all eliminated.
Taking CONFIG_DRM_I915_REQUEST_TIMEOUT in
drivers/gpu/drm/i915/gem/i915_gem_context.c as example, we have the
following output of the preprocessor:
old:
if (((2) != 0) &&
new:
if (( ("2"[0] > '0' && "2"[0] < '9') || "2"[0] == '-' ) &&
New one looks worse, but is also eliminated from the object:
$ size drivers/gpu/drm/i915/gem/i915_gem_context.o.*
textdata bss dec hex filename
520211070 232 53323d04b
drivers/gpu/drm/i915/gem/i915_gem_context.o.new
520211070 232 53323d04b
drivers/gpu/drm/i915/gem/i915_gem_context.o.old
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/i915_utils.h | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_utils.h
b/drivers/gpu/drm/i915/i915_utils.h
index 02bbfa4d68d3..436ce612c46a 100644
--- a/drivers/gpu/drm/i915/i915_utils.h
+++ b/drivers/gpu/drm/i915/i915_utils.h
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
#include
#include
@@ -469,6 +470,9 @@ static inline bool timer_expired(const struct timer_list *t)
*
* Returns 0 if @config is 0, 1 if set to any value.
*/
-#define IS_CONFIG_NONZERO(config) ((config) != 0)
+#define IS_CONFIG_NONZERO(config) (
\
+ (__stringify_1(config)[0] > '0' && __stringify_1(config)[0] < '9') ||
\
+ __stringify_1(config)[0] == '-'
\
+)
#endif /* !__I915_UTILS_H */
--
2.33.0
[PATCH 3/3] Move IS_CONFIG_NONZERO() to kconfig.h
The check for config value doesn't really belong to i915_utils.h - we
are trying to eliminate that utils helper and share them when possible
with other drivers and subsystems.
Rationale for having such macro is in commit
babaab2f4738 ("drm/i915: Encapsulate kconfig constant values inside boolean
predicates")
whereas later it is improved to not break the build if used with
undefined configs. The caveat is detailed in the documentation: unlike
IS_ENABLED(): it's not preprocessor-only logic so can't be used for
things like `#if IS_CONFIG_NONZERO(...)`
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/i915_utils.h | 17 -
include/linux/kconfig.h | 16 ++--
2 files changed, 14 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_utils.h
b/drivers/gpu/drm/i915/i915_utils.h
index 436ce612c46a..62f189e064a9 100644
--- a/drivers/gpu/drm/i915/i915_utils.h
+++ b/drivers/gpu/drm/i915/i915_utils.h
@@ -28,7 +28,6 @@
#include
#include
#include
-#include
#include
#include
@@ -459,20 +458,4 @@ static inline bool timer_expired(const struct timer_list
*t)
return timer_active(t) && !timer_pending(t);
}
-/*
- * This is a lookalike for IS_ENABLED() that takes a kconfig value,
- * e.g. CONFIG_DRM_I915_SPIN_REQUEST, and evaluates whether it is non-zero
- * i.e. whether the configuration is active. Wrapping up the config inside
- * a boolean context prevents clang and smatch from complaining about potential
- * issues in confusing logical-&& with bitwise-& for constants.
- *
- * Sadly IS_ENABLED() itself does not work with kconfig values.
- *
- * Returns 0 if @config is 0, 1 if set to any value.
- */
-#define IS_CONFIG_NONZERO(config) (
\
- (__stringify_1(config)[0] > '0' && __stringify_1(config)[0] < '9') ||
\
- __stringify_1(config)[0] == '-'
\
-)
-
#endif /* !__I915_UTILS_H */
diff --git a/include/linux/kconfig.h b/include/linux/kconfig.h
index 20d1079e92b4..e84f7c1c8e26 100644
--- a/include/linux/kconfig.h
+++ b/include/linux/kconfig.h
@@ -2,6 +2,7 @@
#ifndef __LINUX_KCONFIG_H
#define __LINUX_KCONFIG_H
+#include
#include
#ifdef CONFIG_CPU_BIG_ENDIAN
@@ -26,8 +27,8 @@
#define or(arg1_or_junk, y)__take_second_arg(arg1_or_junk
1, y)
/*
- * Helper macros to use CONFIG_ options in C/CPP expressions. Note that
- * these only work with boolean and tristate options.
+ * Helper macros to use CONFIG_ options in C/CPP expressions. Note that except
+ * for IS_CONFIG_NONZERO, these only work with boolean and tristate options.
*/
/*
@@ -72,4 +73,15 @@
*/
#define IS_ENABLED(option) __or(IS_BUILTIN(option), IS_MODULE(option))
+/*
+ * This is a lookalike for IS_ENABLED(), but works with int kconfig options
+ * with the caveat that it can't be used on preprocessor checks.
+ *
+ * Returns 0 if @config is 0 or undefined, 1 if set to any value.
+ */
+#define IS_CONFIG_NONZERO(config) (
\
+ (__stringify_1(config)[0] > '0' && __stringify_1(config)[0] < '9') ||
\
+ __stringify_1(config)[0] == '-'
\
+)
+
#endif /* __LINUX_KCONFIG_H */
--
2.33.0
[PATCH 0/3] Rename IS_ACTIVE() and move to kconfig.h
As we try to reduce our i915-only helpers, let's try to improve IS_ACTIVE() logic and move to kconfig.h. I'm not 100% happy with the name, but it's the best I could come up with, hopefully a little better than trying to add IS_ACTIVE() to be used broadly. Lucas De Marchi (3): drm/i915: rename IS_ACTIVE drm/i915/utils: do not depend on config being defined Move IS_CONFIG_NONZERO() to kconfig.h drivers/gpu/drm/i915/gem/i915_gem_context.c | 2 +- drivers/gpu/drm/i915/gem/i915_gem_mman.c | 2 +- drivers/gpu/drm/i915/gt/intel_engine.h | 4 ++-- drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c | 2 +- drivers/gpu/drm/i915/gt/intel_engine_types.h | 2 +- .../gpu/drm/i915/gt/intel_execlists_submission.c | 2 +- .../gpu/drm/i915/gt/selftest_engine_heartbeat.c | 4 ++-- drivers/gpu/drm/i915/gt/selftest_execlists.c | 14 +++--- drivers/gpu/drm/i915/i915_config.c | 2 +- drivers/gpu/drm/i915/i915_request.c | 2 +- drivers/gpu/drm/i915/i915_utils.h| 13 - include/linux/kconfig.h | 16 ++-- 12 files changed, 32 insertions(+), 33 deletions(-) -- 2.33.0
[PATCH 1/3] drm/i915: rename IS_ACTIVE
It took me some time to understand the need for IS_ACTIVE and why we
couldn't use kconfig.h. Rename it to something else that would be more
suitable to include in kconfig.h and shared with other subsystems rather
than maintaining it only in i915.
Name here is pretty open for suggestions, but I think this is slightly
better than "active".
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/gem/i915_gem_context.c| 2 +-
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 2 +-
drivers/gpu/drm/i915/gt/intel_engine.h | 4 ++--
drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c | 2 +-
drivers/gpu/drm/i915/gt/intel_engine_types.h | 2 +-
.../gpu/drm/i915/gt/intel_execlists_submission.c | 2 +-
.../gpu/drm/i915/gt/selftest_engine_heartbeat.c| 4 ++--
drivers/gpu/drm/i915/gt/selftest_execlists.c | 14 +++---
drivers/gpu/drm/i915/i915_config.c | 2 +-
drivers/gpu/drm/i915/i915_request.c| 2 +-
drivers/gpu/drm/i915/i915_utils.h | 2 +-
11 files changed, 19 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 8208fd5b72c3..ff748441a0e2 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -761,7 +761,7 @@ static int intel_context_set_gem(struct intel_context *ce,
intel_engine_has_semaphores(ce->engine))
__set_bit(CONTEXT_USE_SEMAPHORES, >flags);
- if (IS_ACTIVE(CONFIG_DRM_I915_REQUEST_TIMEOUT) &&
+ if (IS_CONFIG_NONZERO(CONFIG_DRM_I915_REQUEST_TIMEOUT) &&
ctx->i915->params.request_timeout_ms) {
unsigned int timeout_ms = ctx->i915->params.request_timeout_ms;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index 5130e8ed9564..9e12c026e59f 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
@@ -395,7 +395,7 @@ static vm_fault_t vm_fault_gtt(struct vm_fault *vmf)
/* Track the mmo associated with the fenced vma */
vma->mmo = mmo;
- if (IS_ACTIVE(CONFIG_DRM_I915_USERFAULT_AUTOSUSPEND))
+ if (IS_CONFIG_NONZERO(CONFIG_DRM_I915_USERFAULT_AUTOSUSPEND))
intel_wakeref_auto(>ggtt.userfault_wakeref,
msecs_to_jiffies_timeout(CONFIG_DRM_I915_USERFAULT_AUTOSUSPEND));
diff --git a/drivers/gpu/drm/i915/gt/intel_engine.h
b/drivers/gpu/drm/i915/gt/intel_engine.h
index 87579affb952..f181c8654cbf 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine.h
@@ -273,7 +273,7 @@ static inline bool intel_engine_uses_guc(const struct
intel_engine_cs *engine)
static inline bool
intel_engine_has_preempt_reset(const struct intel_engine_cs *engine)
{
- if (!IS_ACTIVE(CONFIG_DRM_I915_PREEMPT_TIMEOUT))
+ if (!IS_CONFIG_NONZERO(CONFIG_DRM_I915_PREEMPT_TIMEOUT))
return false;
return intel_engine_has_preemption(engine);
@@ -300,7 +300,7 @@ intel_virtual_engine_has_heartbeat(const struct
intel_engine_cs *engine)
static inline bool
intel_engine_has_heartbeat(const struct intel_engine_cs *engine)
{
- if (!IS_ACTIVE(CONFIG_DRM_I915_HEARTBEAT_INTERVAL))
+ if (!IS_CONFIG_NONZERO(CONFIG_DRM_I915_HEARTBEAT_INTERVAL))
return false;
if (intel_engine_is_virtual(engine))
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
index 74775ae961b2..9b2eb0491c9d 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
@@ -207,7 +207,7 @@ static void heartbeat(struct work_struct *wrk)
void intel_engine_unpark_heartbeat(struct intel_engine_cs *engine)
{
- if (!IS_ACTIVE(CONFIG_DRM_I915_HEARTBEAT_INTERVAL))
+ if (!IS_CONFIG_NONZERO(CONFIG_DRM_I915_HEARTBEAT_INTERVAL))
return;
next_heartbeat(engine);
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h
b/drivers/gpu/drm/i915/gt/intel_engine_types.h
index 5ae1207c363b..938b49e41e48 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
@@ -556,7 +556,7 @@ intel_engine_has_semaphores(const struct intel_engine_cs
*engine)
static inline bool
intel_engine_has_timeslices(const struct intel_engine_cs *engine)
{
- if (!IS_ACTIVE(CONFIG_DRM_I915_TIMESLICE_DURATION))
+ if (!IS_CONFIG_NONZERO(CONFIG_DRM_I915_TIMESLICE_DURATION))
return false;
return engine->flags & I915_ENGINE_HAS_TIMESLICES;
diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
index 7147fe80919e..851dce6bfc6f 100644
--- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
+++
Re: [PATCH v3 4/4] drm/rockchip: dsi: Disable PLL clock on bind error
On Tue, Sep 28, 2021 at 02:35:52PM -0700, Brian Norris wrote:
> Fix some error handling here noticed in review of other changes.
>
> Fixes: 2d4f7bdafd70 ("drm/rockchip: dsi: migrate to use dw-mipi-dsi bridge
> driver")
> Signed-off-by: Brian Norris
> Reported-by: Chen-Yu Tsai
> Reviewed-by: Chen-Yu Tsai
Tested-by: Nícolas F. R. A. Prado
Re: [PATCH v3 3/4] drm/rockchip: dsi: Fix unbalanced clock on probe error
On Tue, Sep 28, 2021 at 02:35:51PM -0700, Brian Norris wrote:
> Our probe() function never enabled this clock, so we shouldn't disable
> it if we fail to probe the bridge.
>
> Noted by inspection.
>
> Fixes: 2d4f7bdafd70 ("drm/rockchip: dsi: migrate to use dw-mipi-dsi bridge
> driver")
> Signed-off-by: Brian Norris
> Reviewed-by: Chen-Yu Tsai
> ---
Tested-by: Nícolas F. R. A. Prado
Re: [PATCH v3 2/4] drm/rockchip: dsi: Reconfigure hardware on resume()
On Tue, Sep 28, 2021 at 02:35:50PM -0700, Brian Norris wrote:
> Since commit 43c2de1002d2, we perform most HW configuration in the
> bind() function. This configuration may be lost on suspend/resume, so we
> need to call it again. That may lead to errors like this after system
> suspend/resume:
>
> dw-mipi-dsi-rockchip ff968000.mipi: failed to write command FIFO
> panel-kingdisplay-kd097d04 ff96.mipi.0: failed write init cmds: -110
>
> Tested on Acer Chromebook Tab 10 (RK3399 Gru-Scarlet).
>
> Note that early mailing list versions of this driver borrowed Rockchip's
> downstream/BSP solution, to do HW configuration in mode_set() (which
> *is* called at the appropriate pre-enable() times), but that was
> discarded along the way. I've avoided that still, because mode_set()
> documentation doesn't suggest this kind of purpose as far as I can tell.
>
> Fixes: 43c2de1002d2 ("drm/rockchip: dsi: move all lane config except LCDC mux
> to bind()")
> Cc:
> Signed-off-by: Brian Norris
Tested-by: Nícolas F. R. A. Prado
Re: [PATCH v2] drm/i915/bdb: Fix version check
On Thu, 2021-09-23 at 18:49 +0200, Lukasz Majczak wrote:
> With patch "drm/i915/vbt: Fix backlight parsing for VBT 234+"
> the size of bdb_lfp_backlight_data structure has been increased,
> causing if-statement in the parse_lfp_backlight function
> that comapres this structure size to the one retrieved from BDB,
> always to fail for older revisions.
> This patch calculates expected size of the structure for a given
> BDB version and compares it with the value gathered from BDB.
> Tested on Chromebook Pixelbook (Nocturne) (reports bdb->version = 221)
Fixes: d381baad29b4 ("drm/i915/vbt: Fix backlight parsing for VBT 234+")
>
> Tested-by: Lukasz Majczak
> Signed-off-by: Lukasz Majczak
> ---
> drivers/gpu/drm/i915/display/intel_bios.c | 11 +--
> drivers/gpu/drm/i915/display/intel_vbt_defs.h | 5 +
> 2 files changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
> b/drivers/gpu/drm/i915/display/intel_bios.c
> index 3c25926092de..90eae6da12e0 100644
> --- a/drivers/gpu/drm/i915/display/intel_bios.c
> +++ b/drivers/gpu/drm/i915/display/intel_bios.c
> @@ -428,6 +428,7 @@ parse_lfp_backlight(struct drm_i915_private *i915,
> const struct lfp_backlight_data_entry *entry;
> int panel_type = i915->vbt.panel_type;
> u16 level;
> + size_t exp_size;
>
> backlight_data = find_section(bdb, BDB_LVDS_BACKLIGHT);
> if (!backlight_data)
> @@ -450,9 +451,15 @@ parse_lfp_backlight(struct drm_i915_private *i915,
> return;
> }
>
> + if (bdb->version <= 234)
> + exp_size = EXP_BDB_LFP_BL_DATA_SIZE_REV_234;
> + else if (bdb->version > 234 && bdb->version <= 236)
> + exp_size = EXP_BDB_LFP_BL_DATA_SIZE_REV_236;
> + else
> + exp_size = sizeof(struct bdb_lfp_backlight_data);
Usually we go by the newest(IP version, platform...) to the oldest:
if (bdb->version >= 236)
exp_size = sizeof(struct bdb_lfp_backlight_data);
else if (bdb->version >= 234)
exp_size = offsetof(struct bdb_lfp_backlight_data,
brightness_precision_bits);
else
exp_size = offsetof(struct bdb_lfp_backlight_data, brightness_level);
backlight_control was added in version 191 so no need to set exp_size for older
versions.
> +
> i915->vbt.backlight.type = INTEL_BACKLIGHT_DISPLAY_DDI;
> - if (bdb->version >= 191 &&
> - get_blocksize(backlight_data) >= sizeof(*backlight_data)) {
> + if (bdb->version >= 191 && get_blocksize(backlight_data) >= exp_size) {
> const struct lfp_backlight_control_method *method;
>
> method = _data->backlight_control[panel_type];
> diff --git a/drivers/gpu/drm/i915/display/intel_vbt_defs.h
> b/drivers/gpu/drm/i915/display/intel_vbt_defs.h
> index 330077c2e588..ba9990e5983c 100644
> --- a/drivers/gpu/drm/i915/display/intel_vbt_defs.h
> +++ b/drivers/gpu/drm/i915/display/intel_vbt_defs.h
> @@ -814,6 +814,11 @@ struct lfp_brightness_level {
> u16 reserved;
> } __packed;
>
> +#define EXP_BDB_LFP_BL_DATA_SIZE_REV_234 \
> + offsetof(struct bdb_lfp_backlight_data, brightness_level)
version 234 starts at brightness_level but the size of 234 data must be
included to the size, so it should be:
offsetof(struct bdb_lfp_backlight_data, brightness_precision_bits).
> +#define EXP_BDB_LFP_BL_DATA_SIZE_REV_236 \
> + offsetof(struct bdb_lfp_backlight_data, brightness_precision_bits)
> +
> struct bdb_lfp_backlight_data {
> u8 entry_size;
> struct lfp_backlight_data_entry data[16];
[PATCH] drm/msm/dsi: prevent unintentional integer overflow in dsi_pll_28nm_clk_recalc_rate()
Coverity warns of an unintentional integer overflow
CID 120715 (#1 of 1): Unintentional integer overflow (OVERFLOW_BEFORE_WIDEN)
overflow_before_widen: Potentially overflowing expression ref_clk * sdm_byp_div
with type unsigned int (32 bits, unsigned) is evaluated using 32-bit
arithmetic,
and then used in a context that expects an expression of type unsigned long
(64 bits, unsigned).
To avoid overflow, cast either ref_clk or sdm_byp_div to type unsigned long.
263vco_rate = ref_clk * sdm_byp_div;
Fix this and another possible overflow by casting ref_clk to unsigned long.
Cc: Rob Clark
Cc: Sean Paul
Cc: David Airlie
Cc: Daniel Vetter
Cc: Dmitry Baryshkov
Cc: Abhinav Kumar
Cc: linux-arm-...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: freedr...@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Tim Gardner
---
drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c
index 2da673a2add6..cfe4b30eb96d 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c
@@ -260,7 +260,7 @@ static unsigned long dsi_pll_28nm_clk_recalc_rate(struct
clk_hw *hw,
sdm_byp_div = FIELD(
dsi_phy_read(base +
REG_DSI_28nm_PHY_PLL_SDM_CFG0),
DSI_28nm_PHY_PLL_SDM_CFG0_BYP_DIV) + 1;
- vco_rate = ref_clk * sdm_byp_div;
+ vco_rate = (unsigned long)ref_clk * sdm_byp_div;
} else {
/* sdm mode */
sdm_dc_off = FIELD(
@@ -274,7 +274,7 @@ static unsigned long dsi_pll_28nm_clk_recalc_rate(struct
clk_hw *hw,
sdm_freq_seed = (sdm3 << 8) | sdm2;
DBG("sdm_freq_seed = %d", sdm_freq_seed);
- vco_rate = (ref_clk * (sdm_dc_off + 1)) +
+ vco_rate = ((unsigned long)ref_clk * (sdm_dc_off + 1)) +
mult_frac(ref_clk, sdm_freq_seed, BIT(16));
DBG("vco rate = %lu", vco_rate);
}
--
2.33.0
Re: [PATCH v8 03/12] iommu/mediatek: Add probe_defer for smi-larb
On 29.09.21 03:37, Yong Wu wrote:
Prepare for adding device_link.
The iommu consumer should use device_link to connect with the
smi-larb(supplier). then the smi-larb should run before the iommu
consumer. Here we delay the iommu driver until the smi driver is ready,
then all the iommu consumers always are after the smi driver.
When there is no this patch, if some consumer drivers run before
smi-larb, the supplier link_status is DL_DEV_NO_DRIVER(0) in the
device_link_add, then device_links_driver_bound will use WARN_ON
to complain that the link_status of supplier is not right.
device_is_bound may be more elegant here. but it is not allowed to
EXPORT from https://lore.kernel.org/patchwork/patch/1334670/.
Signed-off-by: Yong Wu
Tested-by: Frank Wunderlich # BPI-R2/MT7623
---
drivers/iommu/mtk_iommu.c| 2 +-
drivers/iommu/mtk_iommu_v1.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index d837adfd1da5..d5848f78a677 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -844,7 +844,7 @@ static int mtk_iommu_probe(struct platform_device *pdev)
id = i;
plarbdev = of_find_device_by_node(larbnode);
- if (!plarbdev) {
+ if (!plarbdev || !plarbdev->dev.driver) {
of_node_put(larbnode);
return -EPROBE_DEFER;
if plarbdev is null doesn't that mean that the device does not exist?
so we should return -ENODEV in that case?
thanks,
Dafna
}
diff --git a/drivers/iommu/mtk_iommu_v1.c b/drivers/iommu/mtk_iommu_v1.c
index 1467ba1e4417..4d7809432239 100644
--- a/drivers/iommu/mtk_iommu_v1.c
+++ b/drivers/iommu/mtk_iommu_v1.c
@@ -602,7 +602,7 @@ static int mtk_iommu_probe(struct platform_device *pdev)
}
plarbdev = of_find_device_by_node(larbnode);
- if (!plarbdev) {
+ if (!plarbdev || !plarbdev->dev.driver) {
of_node_put(larbnode);
return -EPROBE_DEFER;
}
[PATCH] drm/msm: prevent NULL dereference in msm_gpu_crashstate_capture()
Coverity complains of a possible NULL dereference:
CID 120718 (#1 of 1): Dereference null return value (NULL_RETURNS)
23. dereference: Dereferencing a pointer that might be NULL state->bos when
calling msm_gpu_crashstate_get_bo. [show details]
301msm_gpu_crashstate_get_bo(state, submit->bos[i].obj,
302submit->bos[i].iova, submit->bos[i].flags);
Fix this by employing the same state->bos NULL check as is used in the next
for loop.
Cc: Rob Clark
Cc: Sean Paul
Cc: David Airlie
Cc: Daniel Vetter
Cc: linux-arm-...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: freedr...@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Tim Gardner
---
drivers/gpu/drm/msm/msm_gpu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
index 8a3a592da3a4..2c46cd968ac4 100644
--- a/drivers/gpu/drm/msm/msm_gpu.c
+++ b/drivers/gpu/drm/msm/msm_gpu.c
@@ -296,7 +296,7 @@ static void msm_gpu_crashstate_capture(struct msm_gpu *gpu,
state->bos = kcalloc(nr,
sizeof(struct msm_gpu_state_bo), GFP_KERNEL);
- for (i = 0; i < submit->nr_bos; i++) {
+ for (i = 0; state->bos && i < submit->nr_bos; i++) {
if (should_dump(submit, i)) {
msm_gpu_crashstate_get_bo(state,
submit->bos[i].obj,
submit->bos[i].iova,
submit->bos[i].flags);
--
2.33.0
[PATCH v2] drm/msm/dp: only signal audio when disconnected detected at dp_pm_resume
Currently there is audio not working problem after system resume from suspend
if hdmi monitor stay plugged in at DUT. However this problem does not happen
at normal operation but at a particular test case. The root cause is DP driver
signal audio with connected state at resume which trigger audio trying to setup
audio data path through DP main link but failed due to display port is not setup
and enabled by upper layer framework yet. This patch only have DP driver signal
audio only when DP is in disconnected state so that audio option shows correct
state after system resume. DP driver will not signal audio with connected state
until display enabled executed by upper layer framework where display port is
setup completed and main link is running.
Changes in V2:
-- add details commit text
Fixes: 078867ce04ed ("drm/msm/dp: signal audio plugged change at dp_pm_resume")
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/dp/dp_display.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index 0e543a03..6f13008 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -1356,14 +1356,14 @@ static int dp_pm_resume(struct device *dev)
* can not declared display is connected unless
* HDMI cable is plugged in and sink_count of
* dongle become 1
+* also only signal audio when disconnected
*/
- if (dp->link->sink_count)
+ if (dp->link->sink_count) {
dp->dp_display.is_connected = true;
- else
+ } else {
dp->dp_display.is_connected = false;
-
- dp_display_handle_plugged_change(g_dp_display,
- dp->dp_display.is_connected);
+ dp_display_handle_plugged_change(g_dp_display, false);
+ }
DRM_DEBUG_DP("After, sink_count=%d is_connected=%d core_inited=%d
power_on=%d\n",
dp->link->sink_count, dp->dp_display.is_connected,
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
Re: [PATCH v11 14/16] drm/mediatek: add DSC support for mediatek-drm
Hi, Jason:
jason-jh.lin 於 2021年9月21日 週二 下午11:52寫道：
>
> DSC is designed for real-time systems with real-time compression,
> transmission, decompression and display.
> The DSC standard is a specification of the algorithms used for
> compressing and decompressing image display streams, including
> the specification of the syntax and semantics of the compressed
> video bit stream.
Reviewed-by: Chun-Kuang Hu
>
> Signed-off-by: jason-jh.lin
> ---
> rebase on series [1]
>
> [1] drm/mediatek: add support for mediatek SOC MT8192
> - https://patchwork.kernel.org/project/linux-mediatek/list/?series=529489
> ---
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 47 +
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 1 +
> 2 files changed, 48 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> index 23c03e550658..ce6c90b9edef 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> @@ -40,6 +40,12 @@
> #define DITHER_LSB_ERR_SHIFT_G(x) (((x) & 0x7) << 12)
> #define DITHER_ADD_LSHIFT_G(x) (((x) & 0x7) << 4)
>
> +#define DISP_REG_DSC_CON 0x
> +#define DSC_EN BIT(0)
> +#define DSC_DUAL_INOUT BIT(2)
> +#define DSC_BYPASS BIT(4)
> +#define DSC_UFOE_SEL BIT(16)
> +
> #define DISP_REG_OD_EN 0x
> #define DISP_REG_OD_CFG0x0020
> #define OD_RELAYMODE BIT(0)
> @@ -181,6 +187,36 @@ static void mtk_dither_set(struct device *dev, unsigned
> int bpc,
> DISP_DITHERING, cmdq_pkt);
> }
>
> +static void mtk_dsc_config(struct device *dev, unsigned int w,
> + unsigned int h, unsigned int vrefresh,
> + unsigned int bpc, struct cmdq_pkt *cmdq_pkt)
> +{
> + struct mtk_ddp_comp_dev *priv = dev_get_drvdata(dev);
> +
> + /* dsc bypass mode */
> + mtk_ddp_write_mask(cmdq_pkt, DSC_BYPASS, >cmdq_reg, priv->regs,
> + DISP_REG_DSC_CON, DSC_BYPASS);
> + mtk_ddp_write_mask(cmdq_pkt, DSC_UFOE_SEL, >cmdq_reg,
> priv->regs,
> + DISP_REG_DSC_CON, DSC_UFOE_SEL);
> + mtk_ddp_write_mask(cmdq_pkt, DSC_DUAL_INOUT, >cmdq_reg,
> priv->regs,
> + DISP_REG_DSC_CON, DSC_DUAL_INOUT);
> +}
> +
> +static void mtk_dsc_start(struct device *dev)
> +{
> + struct mtk_ddp_comp_dev *priv = dev_get_drvdata(dev);
> +
> + /* write with mask to reserve the value set in mtk_dsc_config */
> + mtk_ddp_write_mask(NULL, DSC_EN, >cmdq_reg, priv->regs,
> DISP_REG_DSC_CON, DSC_EN);
> +}
> +
> +static void mtk_dsc_stop(struct device *dev)
> +{
> + struct mtk_ddp_comp_dev *priv = dev_get_drvdata(dev);
> +
> + writel_relaxed(0x0, priv->regs + DISP_REG_DSC_CON);
> +}
> +
> static void mtk_od_config(struct device *dev, unsigned int w,
> unsigned int h, unsigned int vrefresh,
> unsigned int bpc, struct cmdq_pkt *cmdq_pkt)
> @@ -270,6 +306,14 @@ static const struct mtk_ddp_comp_funcs ddp_dpi = {
> .stop = mtk_dpi_stop,
> };
>
> +static const struct mtk_ddp_comp_funcs ddp_dsc = {
> + .clk_enable = mtk_ddp_clk_enable,
> + .clk_disable = mtk_ddp_clk_disable,
> + .config = mtk_dsc_config,
> + .start = mtk_dsc_start,
> + .stop = mtk_dsc_stop,
> +};
> +
> static const struct mtk_ddp_comp_funcs ddp_dsi = {
> .start = mtk_dsi_ddp_start,
> .stop = mtk_dsi_ddp_stop,
> @@ -339,6 +383,7 @@ static const char * const
> mtk_ddp_comp_stem[MTK_DDP_COMP_TYPE_MAX] = {
> [MTK_DISP_CCORR] = "ccorr",
> [MTK_DISP_COLOR] = "color",
> [MTK_DISP_DITHER] = "dither",
> + [MTK_DISP_DSC] = "dsc",
> [MTK_DISP_GAMMA] = "gamma",
> [MTK_DISP_MUTEX] = "mutex",
> [MTK_DISP_OD] = "od",
> @@ -369,6 +414,8 @@ static const struct mtk_ddp_comp_match
> mtk_ddp_matches[DDP_COMPONENT_ID_MAX] = {
> [DDP_COMPONENT_DITHER] = { MTK_DISP_DITHER,0,
> _dither },
> [DDP_COMPONENT_DPI0]= { MTK_DPI,0, _dpi },
> [DDP_COMPONENT_DPI1]= { MTK_DPI,1, _dpi },
> + [DDP_COMPONENT_DSC0]= { MTK_DISP_DSC, 0, _dsc },
> + [DDP_COMPONENT_DSC1]= { MTK_DISP_DSC, 1, _dsc },
> [DDP_COMPONENT_DSI0]= { MTK_DSI,0, _dsi },
> [DDP_COMPONENT_DSI1]= { MTK_DSI,1, _dsi },
> [DDP_COMPONENT_DSI2]= { MTK_DSI,2, _dsi },
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> index 4c6a98662305..5e6ff12f16ad 100644
>
Re: [PATCH v11 13/16] drm/mediatek: adjust to the alphabetic order for mediatek-drm
Hi, Jason:
jason-jh.lin 於 2021年9月21日 週二 下午11:52寫道：
>
> Adjust to the alphabetic order for the define, function, struct
> and array in mediatek-drm driver
Reviewed-by: Chun-Kuang Hu
>
> Signed-off-by: jason-jh.lin
> ---
> rebase on series [1]
>
> [1] drm/mediatek: add support for mediatek SOC MT8192
> - https://patchwork.kernel.org/project/linux-mediatek/list/?series=529489
> ---
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 126 ++--
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 24 ++--
> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 120 +--
> 3 files changed, 134 insertions(+), 136 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> index b46bc0f5d1a5..23c03e550658 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> @@ -20,26 +20,30 @@
> #include "mtk_drm_ddp_comp.h"
> #include "mtk_drm_crtc.h"
>
> -#define DISP_REG_OD_EN 0x
> -#define DISP_REG_OD_CFG0x0020
> -#define DISP_REG_OD_SIZE 0x0030
> -#define DISP_REG_DITHER_5 0x0114
> -#define DISP_REG_DITHER_7 0x011c
> -#define DISP_REG_DITHER_15 0x013c
> -#define DISP_REG_DITHER_16 0x0140
> -
> -#define DISP_REG_UFO_START 0x
>
> #define DISP_REG_DITHER_EN 0x
> #define DITHER_EN BIT(0)
> #define DISP_REG_DITHER_CFG0x0020
> #define DITHER_RELAY_MODE BIT(0)
> #define DITHER_ENGINE_EN BIT(1)
> +#define DISP_DITHERING BIT(2)
> #define DISP_REG_DITHER_SIZE 0x0030
> +#define DISP_REG_DITHER_5 0x0114
> +#define DISP_REG_DITHER_7 0x011c
> +#define DISP_REG_DITHER_15 0x013c
> +#define DITHER_LSB_ERR_SHIFT_R(x) (((x) & 0x7) << 28)
> +#define DITHER_ADD_LSHIFT_R(x) (((x) & 0x7) << 20)
> +#define DITHER_NEW_BIT_MODEBIT(0)
> +#define DISP_REG_DITHER_16 0x0140
> +#define DITHER_LSB_ERR_SHIFT_B(x) (((x) & 0x7) << 28)
> +#define DITHER_ADD_LSHIFT_B(x) (((x) & 0x7) << 20)
> +#define DITHER_LSB_ERR_SHIFT_G(x) (((x) & 0x7) << 12)
> +#define DITHER_ADD_LSHIFT_G(x) (((x) & 0x7) << 4)
>
> +#define DISP_REG_OD_EN 0x
> +#define DISP_REG_OD_CFG0x0020
> #define OD_RELAYMODE BIT(0)
> -
> -#define UFO_BYPASS BIT(2)
> +#define DISP_REG_OD_SIZE 0x0030
>
> #define DISP_REG_POSTMASK_EN 0x
> #define POSTMASK_ENBIT(0)
> @@ -47,14 +51,8 @@
> #define POSTMASK_RELAY_MODEBIT(0)
> #define DISP_REG_POSTMASK_SIZE 0x0030
>
> -#define DISP_DITHERING BIT(2)
> -#define DITHER_LSB_ERR_SHIFT_R(x) (((x) & 0x7) << 28)
> -#define DITHER_ADD_LSHIFT_R(x) (((x) & 0x7) << 20)
> -#define DITHER_NEW_BIT_MODEBIT(0)
> -#define DITHER_LSB_ERR_SHIFT_B(x) (((x) & 0x7) << 28)
> -#define DITHER_ADD_LSHIFT_B(x) (((x) & 0x7) << 20)
> -#define DITHER_LSB_ERR_SHIFT_G(x) (((x) & 0x7) << 12)
> -#define DITHER_ADD_LSHIFT_G(x) (((x) & 0x7) << 4)
> +#define DISP_REG_UFO_START 0x
> +#define UFO_BYPASS BIT(2)
>
> struct mtk_ddp_comp_dev {
> struct clk *clk;
> @@ -147,8 +145,35 @@ void mtk_dither_set_common(void __iomem *regs, struct
> cmdq_client_reg *cmdq_reg,
> }
> }
>
> +static void mtk_dither_config(struct device *dev, unsigned int w,
> + unsigned int h, unsigned int vrefresh,
> + unsigned int bpc, struct cmdq_pkt *cmdq_pkt)
> +{
> + struct mtk_ddp_comp_dev *priv = dev_get_drvdata(dev);
> +
> + mtk_ddp_write(cmdq_pkt, h << 16 | w, >cmdq_reg, priv->regs,
> DISP_REG_DITHER_SIZE);
> + mtk_ddp_write(cmdq_pkt, DITHER_RELAY_MODE, >cmdq_reg,
> priv->regs,
> + DISP_REG_DITHER_CFG);
> + mtk_dither_set_common(priv->regs, >cmdq_reg, bpc,
> DISP_REG_DITHER_CFG,
> + DITHER_ENGINE_EN, cmdq_pkt);
> +}
> +
> +static void mtk_dither_start(struct device *dev)
> +{
> + struct mtk_ddp_comp_dev *priv = dev_get_drvdata(dev);
> +
> + writel(DITHER_EN, priv->regs + DISP_REG_DITHER_EN);
> +}
> +
> +static void mtk_dither_stop(struct device *dev)
> +{
> + struct mtk_ddp_comp_dev *priv = dev_get_drvdata(dev);
> +
> + writel_relaxed(0x0, priv->regs + DISP_REG_DITHER_EN);
>
Re: [PATCH v11 12/16] drm/mediatek: rename the define of register offset
Hi, Jason:
jason-jh.lin 於 2021年9月21日 週二 下午11:52寫道：
>
> Add DISP_REG prefix for the define of register offset to
> make the difference from the define of register value.
Reviewed-by: Chun-Kuang Hu
>
> Signed-off-by: jason-jh.lin
> ---
> rebase on series [1]
>
> [1] drm/mediatek: add support for mediatek SOC MT8192
> - https://patchwork.kernel.org/project/linux-mediatek/list/?series=529489
> ---
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 61 +++--
> 1 file changed, 31 insertions(+), 30 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> index 839ffae3019c..b46bc0f5d1a5 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> @@ -20,32 +20,32 @@
> #include "mtk_drm_ddp_comp.h"
> #include "mtk_drm_crtc.h"
>
> -#define DISP_OD_EN 0x
> -#define DISP_OD_CFG0x0020
> -#define DISP_OD_SIZE 0x0030
> -#define DISP_DITHER_5 0x0114
> -#define DISP_DITHER_7 0x011c
> -#define DISP_DITHER_15 0x013c
> -#define DISP_DITHER_16 0x0140
> +#define DISP_REG_OD_EN 0x
> +#define DISP_REG_OD_CFG0x0020
> +#define DISP_REG_OD_SIZE 0x0030
> +#define DISP_REG_DITHER_5 0x0114
> +#define DISP_REG_DITHER_7 0x011c
> +#define DISP_REG_DITHER_15 0x013c
> +#define DISP_REG_DITHER_16 0x0140
>
> #define DISP_REG_UFO_START 0x
>
> -#define DISP_DITHER_EN 0x
> +#define DISP_REG_DITHER_EN 0x
> #define DITHER_EN BIT(0)
> -#define DISP_DITHER_CFG0x0020
> +#define DISP_REG_DITHER_CFG0x0020
> #define DITHER_RELAY_MODE BIT(0)
> #define DITHER_ENGINE_EN BIT(1)
> -#define DISP_DITHER_SIZE 0x0030
> +#define DISP_REG_DITHER_SIZE 0x0030
>
> #define OD_RELAYMODE BIT(0)
>
> #define UFO_BYPASS BIT(2)
>
> -#define DISP_POSTMASK_EN 0x
> +#define DISP_REG_POSTMASK_EN 0x
> #define POSTMASK_ENBIT(0)
> -#define DISP_POSTMASK_CFG 0x0020
> +#define DISP_REG_POSTMASK_CFG 0x0020
> #define POSTMASK_RELAY_MODEBIT(0)
> -#define DISP_POSTMASK_SIZE 0x0030
> +#define DISP_REG_POSTMASK_SIZE 0x0030
>
> #define DISP_DITHERING BIT(2)
> #define DITHER_LSB_ERR_SHIFT_R(x) (((x) & 0x7) << 28)
> @@ -130,19 +130,19 @@ void mtk_dither_set_common(void __iomem *regs, struct
> cmdq_client_reg *cmdq_reg,
> return;
>
> if (bpc >= MTK_MIN_BPC) {
> - mtk_ddp_write(cmdq_pkt, 0, cmdq_reg, regs, DISP_DITHER_5);
> - mtk_ddp_write(cmdq_pkt, 0, cmdq_reg, regs, DISP_DITHER_7);
> + mtk_ddp_write(cmdq_pkt, 0, cmdq_reg, regs, DISP_REG_DITHER_5);
> + mtk_ddp_write(cmdq_pkt, 0, cmdq_reg, regs, DISP_REG_DITHER_7);
> mtk_ddp_write(cmdq_pkt,
> DITHER_LSB_ERR_SHIFT_R(MTK_MAX_BPC - bpc) |
> DITHER_ADD_LSHIFT_R(MTK_MAX_BPC - bpc) |
> DITHER_NEW_BIT_MODE,
> - cmdq_reg, regs, DISP_DITHER_15);
> + cmdq_reg, regs, DISP_REG_DITHER_15);
> mtk_ddp_write(cmdq_pkt,
> DITHER_LSB_ERR_SHIFT_B(MTK_MAX_BPC - bpc) |
> DITHER_ADD_LSHIFT_B(MTK_MAX_BPC - bpc) |
> DITHER_LSB_ERR_SHIFT_G(MTK_MAX_BPC - bpc) |
> DITHER_ADD_LSHIFT_G(MTK_MAX_BPC - bpc),
> - cmdq_reg, regs, DISP_DITHER_16);
> + cmdq_reg, regs, DISP_REG_DITHER_16);
> mtk_ddp_write(cmdq_pkt, dither_en, cmdq_reg, regs, cfg);
> }
> }
> @@ -162,16 +162,16 @@ static void mtk_od_config(struct device *dev, unsigned
> int w,
> {
> struct mtk_ddp_comp_dev *priv = dev_get_drvdata(dev);
>
> - mtk_ddp_write(cmdq_pkt, w << 16 | h, >cmdq_reg, priv->regs,
> DISP_OD_SIZE);
> - mtk_ddp_write(cmdq_pkt, OD_RELAYMODE, >cmdq_reg, priv->regs,
> DISP_OD_CFG);
> - mtk_dither_set(dev, bpc, DISP_OD_CFG, cmdq_pkt);
> + mtk_ddp_write(cmdq_pkt, w << 16 | h, >cmdq_reg, priv->regs,
> DISP_REG_OD_SIZE);
> + mtk_ddp_write(cmdq_pkt, OD_RELAYMODE, >cmdq_reg, priv->regs,
> DISP_REG_OD_CFG);
> +
Re: [PATCH v7 2/3] drm/mediatek: implment the dsi hs packets aligned
Hi, Jitao:
Jitao Shi 於 2021年9月16日 週四 上午6:31寫道：
>
> Some dsi devices require the packets on lanes aligned at the end,
> or the screen will shift or scroll.
Reviewed-by: Chun-Kuang Hu
>
> Signed-off-by: Jitao Shi
> ---
> drivers/gpu/drm/mediatek/mtk_dsi.c | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
> b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index 93b40c245f00..9d72e6dce0bf 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -194,6 +194,8 @@ struct mtk_dsi {
> struct clk *hs_clk;
>
> u32 data_rate;
> + /* force dsi line end without dsi_null data */
> + bool hs_packet_end_aligned;
>
> unsigned long mode_flags;
> enum mipi_dsi_pixel_format format;
> @@ -499,6 +501,13 @@ static void mtk_dsi_config_vdo_timing(struct mtk_dsi
> *dsi)
> DRM_WARN("HFP + HBP less than d-phy, FPS will under 60Hz\n");
> }
>
> + if (dsi->hs_packet_end_aligned) {
> + horizontal_sync_active_byte =
> roundup(horizontal_sync_active_byte, dsi->lanes) - 2;
> + horizontal_frontporch_byte =
> roundup(horizontal_frontporch_byte, dsi->lanes) - 2;
> + horizontal_backporch_byte =
> roundup(horizontal_backporch_byte, dsi->lanes) - 2;
> + horizontal_backporch_byte -= (vm->hactive * dsi_tmp_buf_bpp +
> 2) % dsi->lanes;
> + }
> +
> writel(horizontal_sync_active_byte, dsi->regs + DSI_HSA_WC);
> writel(horizontal_backporch_byte, dsi->regs + DSI_HBP_WC);
> writel(horizontal_frontporch_byte, dsi->regs + DSI_HFP_WC);
> @@ -793,6 +802,7 @@ static int mtk_dsi_host_attach(struct mipi_dsi_host *host,
> dsi->lanes = device->lanes;
> dsi->format = device->format;
> dsi->mode_flags = device->mode_flags;
> + dsi->hs_packet_end_aligned = device->hs_packet_end_aligned;
>
> return 0;
> }
> --
> 2.25.1
Re: [PATCH 3/3] drm/mediatek: Fix cursor plane is not config when primary is updating
Hi, Jason:
jason-jh.lin 於 2021年9月29日 週三 下午3:02寫道：
>
> If cursor plane has updated but primary plane config task is not
> finished, mtk_drm_crtc_update_config will call mbox_flush() to clear
> all task in current GCE thread and let cursor plane re-send a new
> GCE task with cursor + primary plane config to replace the unfinished
> GCE task.
>
> So the plane config flag should not be cleared when mailbox callback
> with a error status.
>
> Fixes: 9efb16c2fdd6 ("drm/mediatek: Clear pending flag when cmdq packet is
> done")
> Signed-off-by: jason-jh.lin
> ---
> drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> index 06342df2a0be..fb0d9424acec 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> @@ -281,6 +281,9 @@ static void ddp_cmdq_cb(struct mbox_client *cl, void
> *mssg)
> struct mtk_crtc_state *state;
> unsigned int i;
>
> + if (data->sta != 0)
data->sta is now the standard error code, so data->sta < 0 is an error.
Regards,
Chun-Kuang.
> + return;
> +
> state = to_mtk_crtc_state(mtk_crtc->base.state);
>
> state->pending_config = false;
> --
> 2.18.0
>
Re: [PATCH 2/3] drm/mediatek: Fix pkt buf alloc once but free many times
Hi, Jason:
jason-jh.lin 於 2021年9月29日 週三 下午3:02寫道：
>
> Because mtk_drm_crt_cmdq_pkt_create is called once
> in mtk_drm_crtc_create, the pkt should not be destroy
> at ddp_cmdq_cb.
>
> So move mtk_drm_crtc_pkt_destroy to mtk_drm_crtc_destroy.
Reviewed-by: Chun-Kuang Hu
>
> Fixes: bc9241be73d9 ("drm/mediatek: Add cmdq_handle in mtk_crtc")
> Signed-off-by: jason-jh.lin
> ---
> drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 29 +++--
> 1 file changed, 18 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> index e98871a8c961..06342df2a0be 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> @@ -108,12 +108,30 @@ static void mtk_drm_finish_page_flip(struct
> mtk_drm_crtc *mtk_crtc)
> }
> }
>
> +#if IS_REACHABLE(CONFIG_MTK_CMDQ)
> +static void mtk_drm_cmdq_pkt_destroy(struct cmdq_pkt *pkt)
> +{
> + struct cmdq_client *client = (struct cmdq_client *)pkt->cl;
> +
> + dma_unmap_single(client->chan->mbox->dev, pkt->pa_base, pkt->buf_size,
> +DMA_TO_DEVICE);
> + kfree(pkt->va_base);
> + kfree(pkt);
> +}
> +#endif
> +
> static void mtk_drm_crtc_destroy(struct drm_crtc *crtc)
> {
> struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc);
>
> mtk_mutex_put(mtk_crtc->mutex);
> +#if IS_REACHABLE(CONFIG_MTK_CMDQ)
> + mtk_drm_cmdq_pkt_destroy(_crtc->cmdq_handle);
>
> + if (mtk_crtc->cmdq_client.chan)
> + mbox_free_channel(mtk_crtc->cmdq_client.chan);
> + mtk_crtc->cmdq_client.chan = NULL;
> +#endif
> drm_crtc_cleanup(crtc);
> }
>
> @@ -255,16 +273,6 @@ static int mtk_drm_cmdq_pkt_create(struct cmdq_client
> *client, struct cmdq_pkt *
> return 0;
> }
>
> -static void mtk_drm_cmdq_pkt_destroy(struct cmdq_pkt *pkt)
> -{
> - struct cmdq_client *client = (struct cmdq_client *)pkt->cl;
> -
> - dma_unmap_single(client->chan->mbox->dev, pkt->pa_base, pkt->buf_size,
> -DMA_TO_DEVICE);
> - kfree(pkt->va_base);
> - kfree(pkt);
> -}
> -
> static void ddp_cmdq_cb(struct mbox_client *cl, void *mssg)
> {
> struct cmdq_cb_data *data = mssg;
> @@ -302,7 +310,6 @@ static void ddp_cmdq_cb(struct mbox_client *cl, void
> *mssg)
> }
>
> mtk_crtc->cmdq_vblank_cnt = 0;
> - mtk_drm_cmdq_pkt_destroy(pkt);
> }
> #endif
>
> --
> 2.18.0
>
Re: [Freedreno] [PATCH v2 13/13] drm/msm: Implement HDCP 1.x using the new drm HDCP helpers
On Tue, Sep 28, 2021 at 02:35:09PM -0700, abhin...@codeaurora.org wrote:
> On 2021-09-28 11:02, Sean Paul wrote:
> > On Tue, Sep 21, 2021 at 07:25:41PM -0700, abhin...@codeaurora.org wrote:
> > > On 2021-09-15 13:38, Sean Paul wrote:
> > > > From: Sean Paul
> > > >
> > > > This patch adds HDCP 1.x support to msm DP connectors using the new HDCP
> > > > helpers.
> > > >
> > > > Cc: Stephen Boyd
> > > > Signed-off-by: Sean Paul
> > > > Link:
> > > > https://patchwork.freedesktop.org/patch/msgid/20210913175747.47456-15-s...@poorly.run
> > > > #v1
> > > >
> > > > Changes in v2:
> > > > -Squash [1] into this patch with the following changes (Stephen)
> > > > -Update the sc7180 dtsi file
> > > > -Remove resource names and just use index (Stephen)
> > > >
> > >
> > >
> > > > [1]
> > > > https://patchwork.freedesktop.org/patch/msgid/20210913175747.47456-14-s...@poorly.run
> > > > ---
> >
> > /snip
> >
> > > > diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
> > > > index 904535eda0c4..98731fd262d6 100644
> > > > --- a/drivers/gpu/drm/msm/Makefile
> > > > +++ b/drivers/gpu/drm/msm/Makefile
> > > > @@ -109,6 +109,7 @@ msm-$(CONFIG_DRM_MSM_DP)+= dp/dp_aux.o \
> > > > dp/dp_ctrl.o \
> > > > dp/dp_display.o \
> > > > dp/dp_drm.o \
> > > > + dp/dp_hdcp.o \
> > > > dp/dp_hpd.o \
> > > > dp/dp_link.o \
> > > > dp/dp_panel.o \
> > > > diff --git a/drivers/gpu/drm/msm/dp/dp_debug.c
> > > > b/drivers/gpu/drm/msm/dp/dp_debug.c
> > > > index 2f6247e80e9d..de16fca8782a 100644
> > > > --- a/drivers/gpu/drm/msm/dp/dp_debug.c
> > > > +++ b/drivers/gpu/drm/msm/dp/dp_debug.c
> >
> > /snip
> >
> > > > +static ssize_t dp_hdcp_key_write(struct file *file, const char __user
> > > > *ubuf,
> > > > +size_t len, loff_t *offp)
> > > > +{
> > > > + char *input_buffer;
> > > > + int ret = 0;
> > > > + struct dp_debug_private *debug = file->private_data;
> > > > + struct drm_device *dev;
> > > > +
> > > > + dev = debug->drm_dev;
> > > > +
> > > > + if (len != (DRM_HDCP_KSV_LEN + DP_HDCP_NUM_KEYS *
> > > > DP_HDCP_KEY_LEN))
> > > > + return -EINVAL;
> > > > +
> > > > + if (!debug->hdcp)
> > > > + return -ENOENT;
> > > > +
> > > > + input_buffer = memdup_user_nul(ubuf, len);
> > > > + if (IS_ERR(input_buffer))
> > > > + return PTR_ERR(input_buffer);
> > > > +
> > > > + ret = dp_hdcp_ingest_key(debug->hdcp, input_buffer, len);
> > > > +
> > > > + kfree(input_buffer);
> > > > + if (ret < 0) {
> > > > + DRM_ERROR("Could not ingest HDCP key, ret=%d\n", ret);
> > > > + return ret;
> > > > + }
> > > > +
> > > > + *offp += len;
> > > > + return len;
> > > > +}
> > >
> > > It seems like the HDCP keys written using debugfs, just for my
> > > understanding,
> > > are you storing this in some secure partition and the usermode reads
> > > from it
> > > and writes them here?
> > >
> >
> > We have not sorted out the userspace side of HDCP enablement yet, so it
> > remains
> > to be seen whether the keys will be injected via debugfs/firmware
> > file/property.
> >
> > /snip
> >
> > > > +static int dp_connector_atomic_check(struct drm_connector *connector,
> > > > +struct drm_atomic_state *state)
> > > > +{
> > > > + struct drm_connector_state *conn_state;
> > > > + struct dp_connector_state *dp_state;
> > > > +
> > > > + conn_state = drm_atomic_get_new_connector_state(state,
> > > > connector);
> > > > + dp_state = to_dp_connector_state(conn_state);
> > > > +
> > > > + dp_state->hdcp_transition = drm_hdcp_atomic_check(connector,
> > > > state);
> > >
> > > I have a general question related to the transition flag and overall
> > > tying
> > > the HDCP
> > > enable and authentication to the commit.
> > > So lets say there is a case where the driver needs to disable HDCP.
> > > It could
> > > be due
> > > to link integrity failure OR some other error condition which
> > > usermode is
> > > not aware of.
> > > In that case, we will set this hdcp_transition to true but in the next
> > > commit we will
> > > actually do the authentication. What if usermode doesnt issue a new
> > > frame?
> > > This question arises because currently the link intergrity check is
> > > done
> > > using SW polling
> > > in the previous patchset. But as I had commented there, this occurs
> > > in HW
> > > for us.
> > > I dont see that isr itself in this patchset. So wanted to understand
> > > if
> > > thats part of this
> > > approach to still tie it with commit.
> > >
> > > So if we go with the HW polling based approach which is the preferred
> > > method, we need to
> > > untie this from the commit.
> > >
> >
> > In the case of error, the worker will detect it and try to
> > re-authenticate. If
> > the re-authentication is
Re: [PATCH 1/3] drm/mediatek: Fix crash at using pkt->cl->chan in cmdq_pkt_finalize
Hi, Jason:
jason-jh.lin 於 2021年9月29日 週三 下午3:02寫道：
>
> Because mtk_drm_crtc_create_pkt didn't assign pkt->cl, it will
> crash at using pkt->cl->chan in cmdq_pkt_finalize.
>
> So add struct cmdq_client and let mtk_drm_crtc instance define
> cmdq_client as:
>
> struct mtk_drm_crtc {
> /* client instance data */
> struct cmdq_client cmdq_client;
> };
>
> and in rx_callback function can use pkt->cl to get
> struct cmdq_client.
>
> Fixes: f4be17cd5b14 ("drm/mediatek: Remove struct cmdq_client")
> Signed-off-by: jason-jh.lin
> ---
> drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 73 +
> 1 file changed, 38 insertions(+), 35 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> index 5f81489fc60c..e98871a8c961 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> @@ -52,8 +52,7 @@ struct mtk_drm_crtc {
> boolpending_async_planes;
>
> #if IS_REACHABLE(CONFIG_MTK_CMDQ)
> - struct mbox_client cmdq_cl;
> - struct mbox_chan*cmdq_chan;
> + struct cmdq_client cmdq_client;
> struct cmdq_pkt cmdq_handle;
> u32 cmdq_event;
> u32 cmdq_vblank_cnt;
> @@ -227,8 +226,8 @@ struct mtk_ddp_comp *mtk_drm_ddp_comp_for_plane(struct
> drm_crtc *crtc,
> }
>
> #if IS_REACHABLE(CONFIG_MTK_CMDQ)
> -static int mtk_drm_cmdq_pkt_create(struct mbox_chan *chan, struct cmdq_pkt
> *pkt,
> - size_t size)
> +static int mtk_drm_cmdq_pkt_create(struct cmdq_client *client, struct
> cmdq_pkt *pkt,
> + size_t size)
> {
> struct device *dev;
> dma_addr_t dma_addr;
> @@ -239,8 +238,9 @@ static int mtk_drm_cmdq_pkt_create(struct mbox_chan
> *chan, struct cmdq_pkt *pkt,
> return -ENOMEM;
> }
> pkt->buf_size = size;
> + pkt->cl = (void *)client;
>
> - dev = chan->mbox->dev;
> + dev = client->chan->mbox->dev;
> dma_addr = dma_map_single(dev, pkt->va_base, pkt->buf_size,
> DMA_TO_DEVICE);
> if (dma_mapping_error(dev, dma_addr)) {
> @@ -255,9 +255,11 @@ static int mtk_drm_cmdq_pkt_create(struct mbox_chan
> *chan, struct cmdq_pkt *pkt,
> return 0;
> }
>
> -static void mtk_drm_cmdq_pkt_destroy(struct mbox_chan *chan, struct cmdq_pkt
> *pkt)
> +static void mtk_drm_cmdq_pkt_destroy(struct cmdq_pkt *pkt)
> {
> - dma_unmap_single(chan->mbox->dev, pkt->pa_base, pkt->buf_size,
> + struct cmdq_client *client = (struct cmdq_client *)pkt->cl;
> +
> + dma_unmap_single(client->chan->mbox->dev, pkt->pa_base, pkt->buf_size,
> DMA_TO_DEVICE);
> kfree(pkt->va_base);
> kfree(pkt);
> @@ -265,8 +267,9 @@ static void mtk_drm_cmdq_pkt_destroy(struct mbox_chan
> *chan, struct cmdq_pkt *pk
>
> static void ddp_cmdq_cb(struct mbox_client *cl, void *mssg)
> {
> - struct mtk_drm_crtc *mtk_crtc = container_of(cl, struct mtk_drm_crtc,
> cmdq_cl);
> struct cmdq_cb_data *data = mssg;
> + struct cmdq_pkt *pkt = data->pkt;
> + struct mtk_drm_crtc *mtk_crtc = container_of(pkt->cl, struct
> mtk_drm_crtc, cmdq_client);
I think you should use cl to find struct cmdq_client, and then use
struct cmdq_clint to find struct mtk_drm_crtc.
In the next patch, you could remove the local variable pkt.
> struct mtk_crtc_state *state;
> unsigned int i;
>
> @@ -299,7 +302,7 @@ static void ddp_cmdq_cb(struct mbox_client *cl, void
> *mssg)
> }
>
> mtk_crtc->cmdq_vblank_cnt = 0;
> - mtk_drm_cmdq_pkt_destroy(mtk_crtc->cmdq_chan, data->pkt);
> + mtk_drm_cmdq_pkt_destroy(pkt);
Maybe mtk_drm_cmdq_pkt_destroy(data->pkt); , so you need not the local
variable pkt.
Regards,
Chun-Kuang.
> }
> #endif
>
> @@ -550,24 +553,24 @@ static void mtk_drm_crtc_update_config(struct
> mtk_drm_crtc *mtk_crtc,
> mtk_mutex_release(mtk_crtc->mutex);
> }
> #if IS_REACHABLE(CONFIG_MTK_CMDQ)
> - if (mtk_crtc->cmdq_chan) {
> - mbox_flush(mtk_crtc->cmdq_chan, 2000);
> + if (mtk_crtc->cmdq_client.chan) {
> + mbox_flush(mtk_crtc->cmdq_client.chan, 2000);
> cmdq_handle->cmd_buf_size = 0;
> cmdq_pkt_clear_event(cmdq_handle, mtk_crtc->cmdq_event);
> cmdq_pkt_wfe(cmdq_handle, mtk_crtc->cmdq_event, false);
> mtk_crtc_ddp_config(crtc, cmdq_handle);
> cmdq_pkt_finalize(cmdq_handle);
> - dma_sync_single_for_device(mtk_crtc->cmdq_chan->mbox->dev,
> - cmdq_handle->pa_base,
> - cmdq_handle->cmd_buf_size,
> -
Re: [Intel-gfx] [PATCH] drm/i915: Add ww context to intel_dpt_pin, v2.
On 9/29/21 10:59, Maarten Lankhorst wrote:
Ensure i915_vma_pin_iomap and vma_unpin are done with dpt->obj lock held.
I don't think there's much of a point in merging intel_dpt_pin() with
intel_pin_fb_obj_dpt(), they touch different objects.
Changes since v1:
- Fix using the wrong pointer to retrieve error code (Julia)
Signed-off-by: Maarten Lankhorst
Reported-by: kernel test robot
Reported-by: Julia Lawall
LGTM.
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/i915/display/intel_dpt.c | 40 +++-
1 file changed, 25 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dpt.c
b/drivers/gpu/drm/i915/display/intel_dpt.c
index de62bd77b15e..8f7b1f7534a4 100644
--- a/drivers/gpu/drm/i915/display/intel_dpt.c
+++ b/drivers/gpu/drm/i915/display/intel_dpt.c
@@ -121,32 +121,42 @@ struct i915_vma *intel_dpt_pin(struct i915_address_space
*vm)
intel_wakeref_t wakeref;
struct i915_vma *vma;
void __iomem *iomem;
+ struct i915_gem_ww_ctx ww;
+ int err;
wakeref = intel_runtime_pm_get(>runtime_pm);
atomic_inc(>gpu_error.pending_fb_pin);
- vma = i915_gem_object_ggtt_pin(dpt->obj, NULL, 0, 4096,
- HAS_LMEM(i915) ? 0 : PIN_MAPPABLE);
- if (IS_ERR(vma))
- goto err;
+ for_i915_gem_ww(, err, true) {
+ err = i915_gem_object_lock(dpt->obj, );
+ if (err)
+ continue;
- iomem = i915_vma_pin_iomap(vma);
- i915_vma_unpin(vma);
- if (IS_ERR(iomem)) {
- vma = ERR_CAST(iomem);
- goto err;
- }
+ vma = i915_gem_object_ggtt_pin_ww(dpt->obj, , NULL, 0, 4096,
+ HAS_LMEM(i915) ? 0 :
PIN_MAPPABLE);
+ if (IS_ERR(vma)) {
+ err = PTR_ERR(vma);
+ continue;
+ }
+
+ iomem = i915_vma_pin_iomap(vma);
+ i915_vma_unpin(vma);
- dpt->vma = vma;
- dpt->iomem = iomem;
+ if (IS_ERR(iomem)) {
+ err = PTR_ERR(iomem);
+ continue;
+ }
- i915_vma_get(vma);
+ dpt->vma = vma;
+ dpt->iomem = iomem;
+
+ i915_vma_get(vma);
+ }
-err:
atomic_dec(>gpu_error.pending_fb_pin);
intel_runtime_pm_put(>runtime_pm, wakeref);
- return vma;
+ return err ? ERR_PTR(err) : vma;
}
void intel_dpt_unpin(struct i915_address_space *vm)
Re: [PATCH 2/2] [v2] qcom_scm: hide Kconfig symbol
On Tue 28 Sep 02:50 CDT 2021, Arnd Bergmann wrote: > From: Arnd Bergmann > > Now that SCM can be a loadable module, we have to add another > dependency to avoid link failures when ipa or adreno-gpu are > built-in: > > aarch64-linux-ld: drivers/net/ipa/ipa_main.o: in function `ipa_probe': > ipa_main.c:(.text+0xfc4): undefined reference to `qcom_scm_is_available' > > ld.lld: error: undefined symbol: qcom_scm_is_available > >>> referenced by adreno_gpu.c > >>> gpu/drm/msm/adreno/adreno_gpu.o:(adreno_zap_shader_load) in > >>> archive drivers/built-in.a > > This can happen when CONFIG_ARCH_QCOM is disabled and we don't select > QCOM_MDT_LOADER, but some other module selects QCOM_SCM. Ideally we'd > use a similar dependency here to what we have for QCOM_RPROC_COMMON, > but that causes dependency loops from other things selecting QCOM_SCM. > > This appears to be an endless problem, so try something different this > time: > > - CONFIG_QCOM_SCM becomes a hidden symbol that nothing 'depends on' >but that is simply selected by all of its users > > - All the stubs in include/linux/qcom_scm.h can go away > > - arm-smccc.h needs to provide a stub for __arm_smccc_smc() to >allow compile-testing QCOM_SCM on all architectures. > > - To avoid a circular dependency chain involving RESET_CONTROLLER >and PINCTRL_SUNXI, drop the 'select RESET_CONTROLLER' statement. >According to my testing this still builds fine, and the QCOM >platform selects this symbol already. > > Acked-by: Kalle Valo > Signed-off-by: Arnd Bergmann > --- > Changes in v2: > - drop the 'select RESET_CONTROLLER' line, rather than adding > more of the same > --- > drivers/firmware/Kconfig| 5 +- > drivers/gpu/drm/msm/Kconfig | 4 +- > drivers/iommu/Kconfig | 2 +- > drivers/media/platform/Kconfig | 2 +- > drivers/mmc/host/Kconfig| 2 +- > drivers/net/ipa/Kconfig | 1 + > drivers/net/wireless/ath/ath10k/Kconfig | 2 +- > drivers/pinctrl/qcom/Kconfig| 3 +- > include/linux/arm-smccc.h | 10 > include/linux/qcom_scm.h| 71 - > 10 files changed, 20 insertions(+), 82 deletions(-) > > diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig > index 220a58cf0a44..cda7d7162cbb 100644 > --- a/drivers/firmware/Kconfig > +++ b/drivers/firmware/Kconfig > @@ -203,10 +203,7 @@ config INTEL_STRATIX10_RSU > Say Y here if you want Intel RSU support. > > config QCOM_SCM > - tristate "Qcom SCM driver" > - depends on ARM || ARM64 > - depends on HAVE_ARM_SMCCC > - select RESET_CONTROLLER > + tristate > > config QCOM_SCM_DOWNLOAD_MODE_DEFAULT > bool "Qualcomm download mode enabled by default" > diff --git a/drivers/gpu/drm/msm/Kconfig b/drivers/gpu/drm/msm/Kconfig > index e9c6af78b1d7..3ddf739a6f9b 100644 > --- a/drivers/gpu/drm/msm/Kconfig > +++ b/drivers/gpu/drm/msm/Kconfig > @@ -17,7 +17,7 @@ config DRM_MSM > select DRM_SCHED > select SHMEM > select TMPFS > - select QCOM_SCM if ARCH_QCOM > + select QCOM_SCM > select WANT_DEV_COREDUMP > select SND_SOC_HDMI_CODEC if SND_SOC > select SYNC_FILE > @@ -55,7 +55,7 @@ config DRM_MSM_GPU_SUDO > > config DRM_MSM_HDMI_HDCP > bool "Enable HDMI HDCP support in MSM DRM driver" > - depends on DRM_MSM && QCOM_SCM > + depends on DRM_MSM > default y > help > Choose this option to enable HDCP state machine > diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig > index 124c41adeca1..989c83acbfee 100644 > --- a/drivers/iommu/Kconfig > +++ b/drivers/iommu/Kconfig > @@ -308,7 +308,7 @@ config APPLE_DART > config ARM_SMMU > tristate "ARM Ltd. System MMU (SMMU) Support" > depends on ARM64 || ARM || (COMPILE_TEST && !GENERIC_ATOMIC64) > - depends on QCOM_SCM || !QCOM_SCM #if QCOM_SCM=m this can't be =y > + select QCOM_SCM > select IOMMU_API > select IOMMU_IO_PGTABLE_LPAE > select ARM_DMA_USE_IOMMU if ARM As noted in the RFC, I think you also need to fix QCOM_IOMMU. In particular (iirc) since all the users of the iommu might be modules, which would prevent QCOM_IOMMU from being selected. The rest looks good. Regards, Bjorn > diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig > index 157c924686e4..80321e03809a 100644 > --- a/drivers/media/platform/Kconfig > +++ b/drivers/media/platform/Kconfig > @@ -565,7 +565,7 @@ config VIDEO_QCOM_VENUS > depends on VIDEO_DEV && VIDEO_V4L2 && QCOM_SMEM > depends on (ARCH_QCOM && IOMMU_DMA) || COMPILE_TEST > select QCOM_MDT_LOADER if ARCH_QCOM > - select QCOM_SCM if ARCH_QCOM > + select QCOM_SCM > select VIDEOBUF2_DMA_CONTIG > select V4L2_MEM2MEM_DEV > help > diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig > index
[PATCH 1/1 REPOST] drm: fix colour banding on Lenovo Thinkpad L540 panel
Hi,
there is an issue with Lenovo Thinkpad L540 panel i.e. a bad looking
color banding with dark colors mainly, very similar to that present
in other models as pointed in referenced bugs.
That happens with any kernel starting from 4.8 up to the current.
Bug: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1749420
Bug: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1788308
Reviewed-by: Alex Deucher
Signed-off-by: Francesco Paolo Lovergine
---
drivers/gpu/drm/drm_edid.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 6325877c5fd6..48e06cc33e4d 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -141,6 +141,9 @@ static const struct edid_quirk {
/* LGD panel of HP zBook 17 G2, eDP 10 bpc, but reports unknown bpc */
{ "LGD", 764, EDID_QUIRK_FORCE_10BPC },
+ /* LGD panel of Lenovo L540 reports 8 bpc, but is a 6 bpc panel */
+ { "LGD", 0x038e, EDID_QUIRK_FORCE_6BPC },
+
/* LG Philips LCD LP154W01-A5 */
{ "LPL", 0, EDID_QUIRK_DETAILED_USE_MAXIMUM_SIZE },
{ "LPL", 0x2a00, EDID_QUIRK_DETAILED_USE_MAXIMUM_SIZE },
--
2.30.2
--
Francesco P. Lovergine
Re: [PATCH] [RFC] qcom_scm: hide Kconfig symbol
On Wed 29 Sep 05:04 CDT 2021, Arnd Bergmann wrote: > On Wed, Sep 29, 2021 at 11:51 AM Will Deacon wrote: > > On Mon, Sep 27, 2021 at 05:22:13PM +0200, Arnd Bergmann wrote: > > > > > > diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig > > > index 124c41adeca1..989c83acbfee 100644 > > > --- a/drivers/iommu/Kconfig > > > +++ b/drivers/iommu/Kconfig > > > @@ -308,7 +308,7 @@ config APPLE_DART > > > config ARM_SMMU > > > tristate "ARM Ltd. System MMU (SMMU) Support" > > > depends on ARM64 || ARM || (COMPILE_TEST && !GENERIC_ATOMIC64) > > > - depends on QCOM_SCM || !QCOM_SCM #if QCOM_SCM=m this can't be =y > > > + select QCOM_SCM > > > select IOMMU_API > > > select IOMMU_IO_PGTABLE_LPAE > > > select ARM_DMA_USE_IOMMU if ARM > > > > I don't want to get in the way of this patch because I'm also tired of the > > randconfig failures caused by QCOM_SCM. However, ARM_SMMU is applicable to > > a wide variety of (non-qcom) SoCs and so it seems a shame to require the > > QCOM_SCM code to be included for all of those when it's not strictly needed > > at all. > > Good point, I agree that needs to be fixed. I think this additional > change should do the trick: > ARM_SMMU and QCOM_IOMMU are two separate implementations and both uses QCOM_SCM. So both of them should select QCOM_SCM. "Unfortunately" the Qualcomm portion of ARM_SMMU is builtin unconditionally, so going with something like select QCOM_SCM if ARCH_QCOM would still require the stubs in qcom_scm.h. Regards, Bjorn > --- a/drivers/iommu/Kconfig > +++ b/drivers/iommu/Kconfig > @@ -308,7 +308,6 @@ config APPLE_DART > config ARM_SMMU > tristate "ARM Ltd. System MMU (SMMU) Support" > depends on ARM64 || ARM || (COMPILE_TEST && !GENERIC_ATOMIC64) > - select QCOM_SCM > select IOMMU_API > select IOMMU_IO_PGTABLE_LPAE > select ARM_DMA_USE_IOMMU if ARM > @@ -438,7 +437,7 @@ config QCOM_IOMMU > # Note: iommu drivers cannot (yet?) be built as modules > bool "Qualcomm IOMMU Support" > depends on ARCH_QCOM || (COMPILE_TEST && !GENERIC_ATOMIC64) > - depends on QCOM_SCM=y > + select QCOM_SCM > select IOMMU_API > select IOMMU_IO_PGTABLE_LPAE > select ARM_DMA_USE_IOMMU > > I'll see if that causes any problems for the randconfig builds. > >Arnd
Re: [PATCH v4 02/10] drm/ingenic: Add support for JZ4780 and HDMI output
Hi Paul,
> Am 29.09.2021 um 16:30 schrieb Paul Cercueil :
>
> Hi,
>
> Le mar., sept. 28 2021 at 14:06:03 +0200, H. Nikolaus Schaller
> a écrit :
>> Hi Paul,
>>> Am 28.09.2021 um 12:21 schrieb H. Nikolaus Schaller :
> @@ -1492,10 +1555,16 @@ static int ingenic_drm_init(void)
> {
> int err;
> + if (IS_ENABLED(CONFIG_DRM_INGENIC_DW_HDMI)) {
> + err = platform_driver_register(ingenic_dw_hdmi_driver_ptr);
> + if (err)
> + return err;
> + }
I don't see why you need to register the ingenic-dw-hdmi driver here. Just
register it in the ingenic-dw-hdmi driver.
>>> Ok, I never though about this (as the code was not from me). We apparently
>>> just followed the IPU code pattern (learning by example).
>>> It indeed looks not necessary and would also avoid the
>>> ingenic_dw_hdmi_driver_ptr dependency.
>>> But: what is ingenic_ipu_driver_ptr then good for?
>
> It's done this way because ingenic-drm-drv.c and ingenic-ipu.c are both
> compiled within the same module ingenic-drm.
Ah, I see. Hadn't checked this.
> I'm not sure this is still required, maybe ingenic-ipu.c can be its own
> module now.
What I have seen is that it has its own compatible record. So there could be
load-on-demand by DTS.
>
>>> If we can get rid of this as well, we can drop patch 1/10 ("drm/ingenic:
>>> Fix drm_init error path if IPU was registered") completely.
>> A quick test shows that it *is* required. At least if I configure everything
>> as modules.
>> But like you I can't explain why.
>
> Well, a quick test here shows that it is not required, at least when
> configuring with everything built-in.
IMHO the hdmi driver (module) should be loaded on demand. Not everyone wants to
have it.
Well, that is the problem that needs to be solved...
BR and thanks,
Nikolaus
Re: [PATCH v4 02/10] drm/ingenic: Add support for JZ4780 and HDMI output
Hi,
Le mar., sept. 28 2021 at 14:06:03 +0200, H. Nikolaus Schaller
a écrit :
Hi Paul,
Am 28.09.2021 um 12:21 schrieb H. Nikolaus Schaller
:
@@ -1492,10 +1555,16 @@ static int ingenic_drm_init(void)
{
int err;
+ if (IS_ENABLED(CONFIG_DRM_INGENIC_DW_HDMI)) {
+ err = platform_driver_register(ingenic_dw_hdmi_driver_ptr);
+ if (err)
+ return err;
+ }
I don't see why you need to register the ingenic-dw-hdmi driver
here. Just register it in the ingenic-dw-hdmi driver.
Ok, I never though about this (as the code was not from me). We
apparently just followed the IPU code pattern (learning by example).
It indeed looks not necessary and would also avoid the
ingenic_dw_hdmi_driver_ptr dependency.
But: what is ingenic_ipu_driver_ptr then good for?
It's done this way because ingenic-drm-drv.c and ingenic-ipu.c are both
compiled within the same module ingenic-drm.
I'm not sure this is still required, maybe ingenic-ipu.c can be its own
module now.
If we can get rid of this as well, we can drop patch 1/10
("drm/ingenic: Fix drm_init error path if IPU was registered")
completely.
A quick test shows that it *is* required. At least if I configure
everything as modules.
But like you I can't explain why.
Well, a quick test here shows that it is not required, at least when
configuring with everything built-in.
-Paul
Well, just a very rough idea (may be wrong): the bridge chain is not
like an i2c bus and
clients are not automatically loaded/probed if linked in the device
tree. Therefore the
consumer (ingenic_drm_drv) must register the "clients" like IPU and
HDMI.
BR,
Nikolaus
Re: [PATCH v2 0/4] CMDQ refinement of Mediatek DRM driver
+Jason: Hi, Enric: Please test Jason's series [1], [2]. Does these series fixes your problem? [1] https://patchwork.kernel.org/project/linux-mediatek/list/?series=554759 [2] https://patchwork.kernel.org/project/linux-mediatek/list/?series=554767 Regards, Chun-Kuang. Chun-Kuang Hu 於 2021年9月24日 週五 上午7:43寫道： > > Hi, Enric: > > Enric Balletbo Serra 於 2021年9月24日 週五 上午12:36寫道： > > > > Hi Chun-Kuang, > > > > Missatge de Chun-Kuang Hu del dia dt., 21 de > > set. 2021 a les 15:15: > > > > > > Hi, Enric: > > > > > > Enric Balletbo Serra 於 2021年9月21日 週二 下午4:36寫道： > > > > > > > > Hi Chun-Kuang, > > > > > > > > (again without html format, sorry for the noise) > > > > > > > > Missatge de Chun-Kuang Hu del dia dj., 12 > > > > d’ag. 2021 a les 2:13: > > > > > > > > > > Chun-Kuang Hu 於 2021年8月9日 週一 上午7:47寫道： > > > > > > > > > > > > These refinements include using standard mailbox callback interface, > > > > > > timeout detection, and a fixed cmdq_handle. > > > > > > > > > > For this series, applied to mediatek-drm-next [1]. > > > > > > > > > > [1] > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git/log/?h=mediatek-drm-next > > > > > > > > > > > > > These patches seem to break the display on the Acer Chromebook R 13 > > > > (MT8173) in the current mainline. After running a bisection it pointed > > > > me to the following commit > > > > > > > > commit f4be17cd5b14dd73545b0e014a63ebe9ab5ef837 > > > > Author: Chun-Kuang Hu > > > > Date: Sun Jul 4 15:36:48 2021 +0800 > > > > > > > > drm/mediatek: Remove struct cmdq_client > > > > > > > > Reverting this patch alone is not trivial, so I ended up reverting the > > > > full series, and I can confirm that reverting the full series makes > > > > the display work again. > > > > > > I think you could not just revert "drm/mediatek: Remove struct > > > cmdq_client", you should also revert the patches after it, such as > > > > > > "drm/mediatek: Clear pending flag when cmdq packet is done" > > > "drm/mediatek: Add cmdq_handle in mtk_crtc" > > > "drm/mediatek: Detect CMDQ execution timeout" > > > > > > > Yes, in fact I reverted: > > > > 9efb16c2fdd6 drm/mediatek: Clear pending flag when cmdq packet is done > > bc9241be73d9 drm/mediatek: Add cmdq_handle in mtk_crtc > > 8cdcb3653424 drm/mediatek: Detect CMDQ execution timeout > > f4be17cd5b14 drm/mediatek: Remove struct cmdq_client > > c1ec54b7b5af drm/mediatek: Use mailbox rx_callback instead of cmdq_task_cb > > > > Without these patches 5.15-rc2 works again on my platform. > > > > The commit 'c1ec54b7b5af drm/mediatek: Use mailbox rx_callback instead > > of cmdq_task_cb' alone introduces lots of warnings in the kernel > > > > WARNING: CPU: 0 PID: 0 at drivers/mailbox/mtk-cmdq-mailbox.c:198 > > cmdq_task_exec_done+0xb8/0xe0 > > I think the WARN_ON in cmdq driver should be remove because that > warning show that cmdq_task_cb is not used but I that is what I want. > > > > > I think is just a leftover or the mentioned warning, but that confused > > me a bit doing the bisection. Then, after commit 'f4be17cd5b14 > > drm/mediatek: Remove struct cmdq_client' my system simply gets stuck. > > For now I don't see any obvious mistake but will dig further. > > > > Can I ask you in which platform did you test? And if you can double > > check if your platform is broken too in current mainline? > > I've no environment to test code now. I apply this series because I > assume Yongqiang has test his patch "Clear pending flag when cmdq > packet is done". Before I setup the environment (this may take a long > time), I would find others to fix this problem. > According to your information, "c1ec54b7b5af drm/mediatek: Use mailbox > rx_callback instead of cmdq_task_cb" would cause many warning but > display still work, right? If so, I think we should focus on > "f4be17cd5b14 drm/mediatek: Remove struct cmdq_client". > > Regards, > Chun-Kuang. > > > > > Thanks, > > Enric > > > > > If "drm/mediatek: Remove struct cmdq_client" is the patch cause > > > display abnormal, I think you could compare code w/ and w/o this > > > patch. Focus on the value accuracy, such as cmdq_cl and cmdq_chan. And > > > focus on the flow accuracy, such as mtk_drm_crtc_update_config() and > > > ddp_cmdq_cb(). If this could not find the problem, I think the latest > > > way is to break this patch into small patches, changes little in each > > > small patches and we could finally find out the problem. > > > > > > Regards, > > > Chun-Kuang. > > > > > > > > > > > Unfortunately, after the merge window, different things broke for this > > > > device, and I didn't finish isolating them, and it is not clear to me > > > > yet whether the logs I'm getting are useful for this specific issue or > > > > not. Basically with this series merged the kernel seems to be stuck, > > > > and the display is not working. Latest message is > > > > > > > > [ 12.329173] mtk-iommu 10205000.iommu: Partial TLB flush timed out, > > > > falling back to full flush > > >
Re: [PATCH v2] drm/amd/display: Only define DP 2.0 symbols if not already defined
On 2021-09-28 23:58, Navare, Manasi D wrote:
> [AMD Official Use Only]
>
> We have merged such DRM definition dependencies previously through a topic
> branch in order to avoid redefining inside the driver.
> But yes guarding this with ifdef is good.
>
> Reviewed-by: Manasi Navare
>
Ah, I merged it already. But thanks for your review.
I agree these are better defined in drm headers, with a preparatory
patch if needed by the driver. We're working on cleaning it up and
dropping the driver defines.
Harry
> Manasi
>
> -Original Message-
> From: Zuo, Jerry
> Sent: Tuesday, September 28, 2021 11:11 PM
> To: Wentland, Harry ; Deucher, Alexander
> ; amd-...@lists.freedesktop.org
> Cc: Nikula, Jani ; Li, Sun peng (Leo)
> ; nat...@kernel.org; intel-...@lists.freedesktop.org;
> dri-devel@lists.freedesktop.org; ville.syrj...@linux.intel.com; Navare,
> Manasi D ; Koenig, Christian
> ; Pan, Xinhui ;
> s...@canb.auug.org.au; linux-n...@vger.kernel.org; airl...@gmail.com;
> daniel.vet...@ffwll.ch; Wentland, Harry
> Subject: RE: [PATCH v2] drm/amd/display: Only define DP 2.0 symbols if not
> already defined
>
> [AMD Official Use Only]
>
>> -Original Message-
>> From: Harry Wentland
>> Sent: September 28, 2021 1:08 PM
>> To: Deucher, Alexander ; amd-
>> g...@lists.freedesktop.org; Zuo, Jerry
>> Cc: jani.nik...@intel.com; Li, Sun peng (Leo) ;
>> nat...@kernel.org; intel-...@lists.freedesktop.org; dri-
>> de...@lists.freedesktop.org; ville.syrj...@linux.intel.com;
>> manasi.d.nav...@intel.com; Koenig, Christian
>> ; Pan, Xinhui ;
>> s...@canb.auug.org.au; linux- n...@vger.kernel.org; airl...@gmail.com;
>> daniel.vet...@ffwll.ch; Wentland, Harry
>> Subject: [PATCH v2] drm/amd/display: Only define DP 2.0 symbols if not
>> already defined
>>
>> [Why]
>> For some reason we're defining DP 2.0 definitions inside our driver.
>> Now that patches to introduce relevant definitions are slated to be
>> merged into drm- next this is causing conflicts.
>>
>> In file included from drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c:33:
>> In file included
>> from ./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgpu.h:70:
>> In file included
>> from ./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgpu_mode.h:36:
>> ./include/drm/drm_dp_helper.h:1322:9: error:
>> 'DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER' macro redefined [-
>> Werror,-Wmacro-redefined]
>> ^
>> ./drivers/gpu/drm/amd/amdgpu/../display/dc/dc_dp_types.h:881:9: note:
>> previous definition is here
>> ^
>> 1 error generated.
>>
>> v2: Add one missing endif
>>
>> [How]
>> Guard all display driver defines with #ifndef for now. Once we pull in
>> the new definitions into amd-staging-drm-next we will follow up and
>> drop definitions from our driver and provide follow-up header updates
>> for any addition DP
>> 2.0 definitions required by our driver.
>>
>> Signed-off-by: Harry Wentland
>
> Reviewed-by: Fangzhi Zuo
>
>> ---
>> drivers/gpu/drm/amd/display/dc/dc_dp_types.h | 54
>> ++--
>> 1 file changed, 49 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/display/dc/dc_dp_types.h
>> b/drivers/gpu/drm/amd/display/dc/dc_dp_types.h
>> index a5e798b5da79..9de86ff5ef1b 100644
>> --- a/drivers/gpu/drm/amd/display/dc/dc_dp_types.h
>> +++ b/drivers/gpu/drm/amd/display/dc/dc_dp_types.h
>> @@ -860,28 +860,72 @@ struct psr_caps { };
>>
>> #if defined(CONFIG_DRM_AMD_DC_DCN)
>> +#ifndef DP_MAIN_LINK_CHANNEL_CODING_CAP
>> #define DP_MAIN_LINK_CHANNEL_CODING_CAP 0x006
>> +#endif
>> +#ifndef DP_SINK_VIDEO_FALLBACK_FORMATS
>> #define DP_SINK_VIDEO_FALLBACK_FORMATS 0x020
>> +#endif
>> +#ifndef DP_FEC_CAPABILITY_1
>> #define DP_FEC_CAPABILITY_1 0x091
>> +#endif
>> +#ifndef DP_DFP_CAPABILITY_EXTENSION_SUPPORT
>> #define DP_DFP_CAPABILITY_EXTENSION_SUPPORT 0x0A3
>> +#endif
>> +#ifndef DP_DSC_CONFIGURATION
>> #define DP_DSC_CONFIGURATION 0x161
>> +#endif
>> +#ifndef DP_PHY_SQUARE_PATTERN
>> #define DP_PHY_SQUARE_PATTERN0x249
>> +#endif
>> +#ifndef DP_128b_132b_SUPPORTED_LINK_RATES
>> #define DP_128b_132b_SUPPORTED_LINK_RATES0x2215
>> +#endif
>> +#ifndef DP_128b_132b_TRAINING_AUX_RD_INTERVAL
>> #define DP_128b_132b_TRAINING_AUX_RD_INTERVAL
>> 0x2216
>> +#endif
>> +#ifndef DP_TEST_264BIT_CUSTOM_PATTERN_7_0
>> #define DP_TEST_264BIT_CUSTOM_PATTERN_7_00X2230
>> +#endif
>> +#ifndef DP_TEST_264BIT_CUSTOM_PATTERN_263_256
>> #define DP_TEST_264BIT_CUSTOM_PATTERN_263_256
>> 0X2250
>> +#endif
>> +#ifndef DP_DSC_SUPPORT_AND_DECODER_COUNT
>> #define DP_DSC_SUPPORT_AND_DECODER_COUNT 0x2260
>> +#endif
>> +#ifndef DP_DSC_MAX_SLICE_COUNT_AND_AGGREGATION_0
>> #define DP_DSC_MAX_SLICE_COUNT_AND_AGGREGATION_0
>> 0x2270
>> -# define DP_DSC_DECODER_0_MAXIMUM_SLICE_COUNT_MASK (1 <<
>> 0)
>> -# define DP_DSC_DECODER_0_AGGREGATION_SUPPORT_MASK
>>
Re: [PATCH v1 2/4] dt-bindings: display: mediatek: add MT8195 hdmi bindings
On Wed, 29 Sep 2021 11:44:23 +0200, Guillaume Ranquet wrote: > Add Mediatek HDMI and HDMI-DDC bindings for MT8195 SoC. > > Signed-off-by: Guillaume Ranquet > --- > .../mediatek/mediatek,mt8195-hdmi-ddc.yaml| 45 + > .../mediatek/mediatek,mt8195-hdmi.yaml| 98 +++ > 2 files changed, 143 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/mediatek/mediatek,mt8195-hdmi-ddc.yaml > create mode 100644 > Documentation/devicetree/bindings/display/mediatek/mediatek,mt8195-hdmi.yaml > My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check' on your patch (DT_CHECKER_FLAGS is new in v5.13): yamllint warnings/errors: dtschema/dtc warnings/errors: /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/mediatek/mediatek,mt8195-hdmi.example.dt.yaml: example-0: hdmi@1c30:reg:0: [0, 472907776, 0, 4096] is too long From schema: /usr/local/lib/python3.8/dist-packages/dtschema/schemas/reg.yaml /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/mediatek/mediatek,mt8195-hdmi.example.dt.yaml: hdmi@1c30: 'ddc-i2c-bus', 'power-domains' do not match any of the regexes: 'pinctrl-[0-9]+' From schema: /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/mediatek/mediatek,mt8195-hdmi.yaml doc reference errors (make refcheckdocs): See https://patchwork.ozlabs.org/patch/1534287 This check can fail if there are any dependencies. The base for a patch series is generally the most recent rc1. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit.
Re: [Intel-gfx] [PATCH v5 01/13] drm/ttm: stop calling tt_swapin in vm_access
On Wed, 29 Sept 2021 at 13:01, Christian König wrote:
>
> Am 27.09.21 um 18:14 schrieb Matthew Auld:
> > On Mon, 27 Sept 2021 at 12:47, Christian König
> > wrote:
> >> Any objections that I just push patches 1-7 to drm-misc-next?
> > Please go ahead Christian. Thanks.
>
> Well I've pushed patches #1-#4 because #5 won't apply on current
> drm-misc-next (some conflict in i915).
>
> Could you rebase this an/or request backmerging of drm-next into
> drm-misc-next when potential i915 prerequisites have landed there.
Version which should apply to drm-misc-next:
https://patchwork.freedesktop.org/series/95219/
>
> Thanks,
> Christian.
>
> >
> >> Christian.
> >>
> >> Am 27.09.21 um 13:41 schrieb Matthew Auld:
> >>> In commit:
> >>>
> >>> commit 09ac4fcb3f255e9225967c75f5893325c116cdbe
> >>> Author: Felix Kuehling
> >>> Date: Thu Jul 13 17:01:16 2017 -0400
> >>>
> >>> drm/ttm: Implement vm_operations_struct.access v2
> >>>
> >>> we added the vm_access hook, where we also directly call tt_swapin for
> >>> some reason. If something is swapped-out then the ttm_tt must also be
> >>> unpopulated, and since access_kmap should also call tt_populate, if
> >>> needed, then swapping-in will already be handled there.
> >>>
> >>> If anything, calling tt_swapin directly here would likely always fail
> >>> since the tt->pages won't yet be populated, or worse since the tt->pages
> >>> array is never actually cleared in unpopulate this might lead to a nasty
> >>> uaf.
> >>>
> >>> Fixes: 09ac4fcb3f25 ("drm/ttm: Implement vm_operations_struct.access v2")
> >>> Signed-off-by: Matthew Auld
> >>> Cc: Thomas Hellström
> >>> Cc: Christian König
> >>> Reviewed-by: Thomas Hellström
> >>> Reviewed-by: Christian König
> >>> ---
> >>>drivers/gpu/drm/ttm/ttm_bo_vm.c | 5 -
> >>>1 file changed, 5 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c
> >>> b/drivers/gpu/drm/ttm/ttm_bo_vm.c
> >>> index f56be5bc0861..5b9b7fd01a69 100644
> >>> --- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
> >>> +++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
> >>> @@ -519,11 +519,6 @@ int ttm_bo_vm_access(struct vm_area_struct *vma,
> >>> unsigned long addr,
> >>>
> >>>switch (bo->resource->mem_type) {
> >>>case TTM_PL_SYSTEM:
> >>> - if (unlikely(bo->ttm->page_flags & TTM_PAGE_FLAG_SWAPPED)) {
> >>> - ret = ttm_tt_swapin(bo->ttm);
> >>> - if (unlikely(ret != 0))
> >>> - return ret;
> >>> - }
> >>>fallthrough;
> >>>case TTM_PL_TT:
> >>>ret = ttm_bo_vm_access_kmap(bo, offset, buf, len, write);
>
[PATCH 3/3] drm/ttm: add TTM_TT_FLAG_EXTERNAL_MAPPABLE
In commit:
commit 667a50db0477d47fdff01c666f5ee1ce26b5264c
Author: Thomas Hellstrom
Date: Fri Jan 3 11:17:18 2014 +0100
drm/ttm: Refuse to fault (prime-) imported pages
we introduced the restriction that imported pages should not be directly
mappable through TTM(this also extends to userptr). In the next patch we
want to introduce a shmem_tt backend, which should follow all the
existing rules with TTM_PAGE_FLAG_EXTERNAL, since it will need to handle
swapping itself, but with the above mapping restriction lifted.
v2(Christian):
- Don't OR together EXTERNAL and EXTERNAL_MAPPABLE in the definition
of EXTERNAL_MAPPABLE, just leave it the caller to handle this
correctly, otherwise we might encounter subtle issues.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Christian König
---
drivers/gpu/drm/ttm/ttm_bo_vm.c | 6 --
drivers/gpu/drm/ttm/ttm_tt.c| 3 +++
include/drm/ttm/ttm_tt.h| 19 ---
3 files changed, 23 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
index 950f4f132802..33680c94127c 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
@@ -163,8 +163,10 @@ vm_fault_t ttm_bo_vm_reserve(struct ttm_buffer_object *bo,
* (if at all) by redirecting mmap to the exporter.
*/
if (bo->ttm && (bo->ttm->page_flags & TTM_TT_FLAG_EXTERNAL)) {
- dma_resv_unlock(bo->base.resv);
- return VM_FAULT_SIGBUS;
+ if (!(bo->ttm->page_flags & TTM_TT_FLAG_EXTERNAL_MAPPABLE)) {
+ dma_resv_unlock(bo->base.resv);
+ return VM_FAULT_SIGBUS;
+ }
}
return 0;
diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
index 86f31fde6e35..7e83c00a3f48 100644
--- a/drivers/gpu/drm/ttm/ttm_tt.c
+++ b/drivers/gpu/drm/ttm/ttm_tt.c
@@ -84,6 +84,9 @@ int ttm_tt_create(struct ttm_buffer_object *bo, bool
zero_alloc)
if (unlikely(bo->ttm == NULL))
return -ENOMEM;
+ WARN_ON(bo->ttm->page_flags & TTM_TT_FLAG_EXTERNAL_MAPPABLE &&
+ !(bo->ttm->page_flags & TTM_TT_FLAG_EXTERNAL));
+
return 0;
}
diff --git a/include/drm/ttm/ttm_tt.h b/include/drm/ttm/ttm_tt.h
index 86d74069be3e..f20832139815 100644
--- a/include/drm/ttm/ttm_tt.h
+++ b/include/drm/ttm/ttm_tt.h
@@ -67,13 +67,26 @@ struct ttm_tt {
* Note that enum ttm_bo_type.ttm_bo_type_sg objects will always enable
* this flag.
*
+* TTM_TT_FLAG_EXTERNAL_MAPPABLE: Same behaviour as
+* TTM_TT_FLAG_EXTERNAL, but with the reduced restriction that it is
+* still valid to use TTM to map the pages directly. This is useful when
+* implementing a ttm_tt backend which still allocates driver owned
+* pages underneath(say with shmem).
+*
+* Note that since this also implies TTM_TT_FLAG_EXTERNAL, the usage
+* here should always be:
+*
+* page_flags = TTM_TT_FLAG_EXTERNAL |
+*TTM_TT_FLAG_EXTERNAL_MAPPABLE;
+*
* TTM_TT_FLAG_PRIV_POPULATED: TTM internal only. DO NOT USE. This is
* set by TTM after ttm_tt_populate() has successfully returned, and is
* then unset when TTM calls ttm_tt_unpopulate().
*/
-#define TTM_TT_FLAG_SWAPPED(1 << 0)
-#define TTM_TT_FLAG_ZERO_ALLOC (1 << 1)
-#define TTM_TT_FLAG_EXTERNAL (1 << 2)
+#define TTM_TT_FLAG_SWAPPED(1 << 0)
+#define TTM_TT_FLAG_ZERO_ALLOC (1 << 1)
+#define TTM_TT_FLAG_EXTERNAL (1 << 2)
+#define TTM_TT_FLAG_EXTERNAL_MAPPABLE (1 << 3)
#define TTM_TT_FLAG_PRIV_POPULATED (1 << 31)
uint32_t page_flags;
--
2.26.3
[PATCH 2/3] drm/ttm: add some kernel-doc for TTM_TT_FLAG_*
Move it to inline kernel-doc, otherwise we can't add empty lines it
seems. Also drop the kernel-doc for pages_list, which doesn't seem to
exist.
v2(Christian):
- Add a note that FLAG_SWAPPED shouldn't need to be touched by drivers.
- Mention what FLAG_POPULATED does.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Christian König
Reviewed-by: Christian König
---
include/drm/ttm/ttm_tt.h | 60 +++-
1 file changed, 41 insertions(+), 19 deletions(-)
diff --git a/include/drm/ttm/ttm_tt.h b/include/drm/ttm/ttm_tt.h
index b023cd58ff38..86d74069be3e 100644
--- a/include/drm/ttm/ttm_tt.h
+++ b/include/drm/ttm/ttm_tt.h
@@ -38,35 +38,57 @@ struct ttm_resource;
struct ttm_buffer_object;
struct ttm_operation_ctx;
-#define TTM_TT_FLAG_SWAPPED(1 << 0)
-#define TTM_TT_FLAG_ZERO_ALLOC (1 << 1)
-#define TTM_TT_FLAG_EXTERNAL (1 << 2)
-
-#define TTM_TT_FLAG_PRIV_POPULATED (1 << 31)
-
/**
- * struct ttm_tt
- *
- * @pages: Array of pages backing the data.
- * @page_flags: see TTM_TT_FLAG_*
- * @num_pages: Number of pages in the page array.
- * @sg: for SG objects via dma-buf
- * @dma_address: The DMA (bus) addresses of the pages
- * @swap_storage: Pointer to shmem struct file for swap storage.
- * @pages_list: used by some page allocation backend
- * @caching: The current caching state of the pages, see enum ttm_caching.
- *
- * This is a structure holding the pages, caching- and aperture binding
- * status for a buffer object that isn't backed by fixed (VRAM / AGP)
+ * struct ttm_tt - This is a structure holding the pages, caching- and aperture
+ * binding status for a buffer object that isn't backed by fixed (VRAM / AGP)
* memory.
*/
struct ttm_tt {
+ /** @pages: Array of pages backing the data. */
struct page **pages;
+ /**
+* @page_flags: The page flags.
+*
+* Supported values:
+*
+* TTM_TT_FLAG_SWAPPED: Set by TTM when the pages have been unpopulated
+* and swapped out by TTM. Calling ttm_tt_populate() will then swap the
+* pages back in, and unset the flag. Drivers should in general never
+* need to touch this.
+*
+* TTM_TT_FLAG_ZERO_ALLOC: Set if the pages will be zeroed on
+* allocation.
+*
+* TTM_TT_FLAG_EXTERNAL: Set if the underlying pages were allocated
+* externally, like with dma-buf or userptr. This effectively disables
+* TTM swapping out such pages. Also important is to prevent TTM from
+* ever directly mapping these pages.
+*
+* Note that enum ttm_bo_type.ttm_bo_type_sg objects will always enable
+* this flag.
+*
+* TTM_TT_FLAG_PRIV_POPULATED: TTM internal only. DO NOT USE. This is
+* set by TTM after ttm_tt_populate() has successfully returned, and is
+* then unset when TTM calls ttm_tt_unpopulate().
+*/
+#define TTM_TT_FLAG_SWAPPED(1 << 0)
+#define TTM_TT_FLAG_ZERO_ALLOC (1 << 1)
+#define TTM_TT_FLAG_EXTERNAL (1 << 2)
+
+#define TTM_TT_FLAG_PRIV_POPULATED (1 << 31)
uint32_t page_flags;
+ /** @num_pages: Number of pages in the page array. */
uint32_t num_pages;
+ /** @sg: for SG objects via dma-buf. */
struct sg_table *sg;
+ /** @dma_address: The DMA (bus) addresses of the pages. */
dma_addr_t *dma_address;
+ /** @swap_storage: Pointer to shmem struct file for swap storage. */
struct file *swap_storage;
+ /**
+* @caching: The current caching state of the pages, see enum
+* ttm_caching.
+*/
enum ttm_caching caching;
};
--
2.26.3
[PATCH 1/3] drm/ttm: s/FLAG_SG/FLAG_EXTERNAL/
It covers more than just ttm_bo_type_sg usage, like with say dma-buf,
since one other user is userptr in amdgpu, and in the future we might
have some more. Hence EXTERNAL is likely a more suitable name.
v2(Christian):
- Rename these to TTM_TT_FLAGS_*
- Fix up all the holes in the flag values
Suggested-by: Christian König
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Christian König
Acked-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 10 +-
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 6 +++---
drivers/gpu/drm/nouveau/nouveau_bo.c| 4 ++--
drivers/gpu/drm/radeon/radeon_ttm.c | 8
drivers/gpu/drm/ttm/ttm_bo.c| 4 ++--
drivers/gpu/drm/ttm/ttm_bo_util.c | 4 ++--
drivers/gpu/drm/ttm/ttm_bo_vm.c | 2 +-
drivers/gpu/drm/ttm/ttm_pool.c | 2 +-
drivers/gpu/drm/ttm/ttm_tt.c| 24
include/drm/ttm/ttm_device.h| 2 +-
include/drm/ttm/ttm_tt.h| 18 +-
11 files changed, 42 insertions(+), 42 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 60b12bb55244..e8d70b6e6737 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -894,7 +894,7 @@ static int amdgpu_ttm_backend_bind(struct ttm_device *bdev,
DRM_ERROR("failed to pin userptr\n");
return r;
}
- } else if (ttm->page_flags & TTM_PAGE_FLAG_SG) {
+ } else if (ttm->page_flags & TTM_TT_FLAG_EXTERNAL) {
if (!ttm->sg) {
struct dma_buf_attachment *attach;
struct sg_table *sgt;
@@ -1130,7 +1130,7 @@ static int amdgpu_ttm_tt_populate(struct ttm_device *bdev,
return 0;
}
- if (ttm->page_flags & TTM_PAGE_FLAG_SG)
+ if (ttm->page_flags & TTM_TT_FLAG_EXTERNAL)
return 0;
ret = ttm_pool_alloc(>mman.bdev.pool, ttm, ctx);
@@ -1165,7 +1165,7 @@ static void amdgpu_ttm_tt_unpopulate(struct ttm_device
*bdev,
return;
}
- if (ttm->page_flags & TTM_PAGE_FLAG_SG)
+ if (ttm->page_flags & TTM_TT_FLAG_EXTERNAL)
return;
for (i = 0; i < ttm->num_pages; ++i)
@@ -1198,8 +1198,8 @@ int amdgpu_ttm_tt_set_userptr(struct ttm_buffer_object
*bo,
return -ENOMEM;
}
- /* Set TTM_PAGE_FLAG_SG before populate but after create. */
- bo->ttm->page_flags |= TTM_PAGE_FLAG_SG;
+ /* Set TTM_TT_FLAG_EXTERNAL before populate but after create. */
+ bo->ttm->page_flags |= TTM_TT_FLAG_EXTERNAL;
gtt = (void *)bo->ttm;
gtt->userptr = addr;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index f0a61a9474fc..8beef57ba52b 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -182,7 +182,7 @@ static struct ttm_tt *i915_ttm_tt_create(struct
ttm_buffer_object *bo,
if (obj->flags & I915_BO_ALLOC_CPU_CLEAR &&
man->use_tt)
- page_flags |= TTM_PAGE_FLAG_ZERO_ALLOC;
+ page_flags |= TTM_TT_FLAG_ZERO_ALLOC;
ret = ttm_tt_init(_tt->ttm, bo, page_flags,
i915_ttm_select_tt_caching(obj));
@@ -451,7 +451,7 @@ static int i915_ttm_accel_move(struct ttm_buffer_object *bo,
if (bo->type == ttm_bo_type_kernel)
return -EINVAL;
- if (ttm && !(ttm->page_flags & TTM_PAGE_FLAG_ZERO_ALLOC))
+ if (ttm && !(ttm->page_flags & TTM_TT_FLAG_ZERO_ALLOC))
return 0;
intel_engine_pm_get(i915->gt.migrate.context->engine);
@@ -525,7 +525,7 @@ static int i915_ttm_move(struct ttm_buffer_object *bo, bool
evict,
/* Populate ttm with pages if needed. Typically system memory. */
if (bo->ttm && (dst_man->use_tt ||
- (bo->ttm->page_flags & TTM_PAGE_FLAG_SWAPPED))) {
+ (bo->ttm->page_flags & TTM_TT_FLAG_SWAPPED))) {
ret = ttm_tt_populate(bo->bdev, bo->ttm, ctx);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 33dca2565cca..b2c7e0802ac3 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -1249,7 +1249,7 @@ nouveau_ttm_tt_populate(struct ttm_device *bdev,
struct ttm_tt *ttm_dma = (void *)ttm;
struct nouveau_drm *drm;
struct device *dev;
- bool slave = !!(ttm->page_flags & TTM_PAGE_FLAG_SG);
+ bool slave = !!(ttm->page_flags & TTM_TT_FLAG_EXTERNAL);
if (ttm_tt_is_populated(ttm))
return 0;
@@ -1272,7 +1272,7 @@ nouveau_ttm_tt_unpopulate(struct ttm_device *bdev,
{
Re: [PATCH v4 02/10] drm/ingenic: Add support for JZ4780 and HDMI output
Hi Paul,
> Am 28.09.2021 um 14:06 schrieb H. Nikolaus Schaller :
>
> Hi Paul,
>
>> Am 28.09.2021 um 12:21 schrieb H. Nikolaus Schaller :
>>
@@ -1492,10 +1555,16 @@ static int ingenic_drm_init(void)
{
int err;
+ if (IS_ENABLED(CONFIG_DRM_INGENIC_DW_HDMI)) {
+ err = platform_driver_register(ingenic_dw_hdmi_driver_ptr);
+ if (err)
+ return err;
+ }
>>>
>>> I don't see why you need to register the ingenic-dw-hdmi driver here. Just
>>> register it in the ingenic-dw-hdmi driver.
>>
>> Ok, I never though about this (as the code was not from me). We apparently
>> just followed the IPU code pattern (learning by example).
>>
>> It indeed looks not necessary and would also avoid the
>> ingenic_dw_hdmi_driver_ptr dependency.
>>
>> But: what is ingenic_ipu_driver_ptr then good for?
>>
>> If we can get rid of this as well, we can drop patch 1/10 ("drm/ingenic: Fix
>> drm_init error path if IPU was registered") completely.
>
> A quick test shows that it *is* required. At least if I configure everything
> as modules.
> But like you I can't explain why.
>
> Well, just a very rough idea (may be wrong): the bridge chain is not like an
> i2c bus and
> clients are not automatically loaded/probed if linked in the device tree.
> Therefore the
> consumer (ingenic_drm_drv) must register the "clients" like IPU and HDMI.
Any suggestion how to proceed here for v5?
BR,
Nikolaus
Re: [PATCH] drm: document pre-multiplied assumptions
On Wed, 29 Sep 2021 09:54:14 + Simon Ser wrote: > When a plane is missing the "alpha blend mode" property, KMS drivers > will use the pre-multiplied mode. > > Signed-off-by: Simon Ser > Cc: Daniel Vetter > Cc: Pekka Paalanen > --- > drivers/gpu/drm/drm_blend.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c > index ec37cbfabb50..eebb32ba84d7 100644 > --- a/drivers/gpu/drm/drm_blend.c > +++ b/drivers/gpu/drm/drm_blend.c > @@ -185,6 +185,9 @@ > *plane does not expose the "alpha" property, then this is > *assumed to be 1.0 > * > + * When a plane is missing this property, the plane uses the > + * "Pre-multiplied" equation. > + * > * Note that all the property extensions described here apply either to the > * plane or the CRTC (e.g. for the background color, which currently is not > * exposed and assumed to be black). Hi Simon, thank you! :-D I have no idea if that's correct though, but also nothing against it, and it does help with what I ranted about in https://lists.freedesktop.org/archives/wayland-devel/2021-September/041993.html so is it appropriate to offer my Acked-by: Pekka Paalanen ? Thanks, pq pgpD62oADJVR6.pgp Description: OpenPGP digital signature
Re: [PATCH v5 10/13] drm/i915: try to simplify make_{un}shrinkable
On Mon, 2021-09-27 at 12:41 +0100, Matthew Auld wrote:
> Drop the atomic shrink_pin stuff, and just have make_{un}shrinkable
> update the shrinker visible lists immediately. This at least
> simplifies
> the next patch, and does make the behaviour more obvious. The
> potential
> downside is that make_unshrinkable now grabs a global lock even when
> the
> object itself is no longer shrinkable(transitioning from purgeable <-
> >
> shrinkable doesn't seem to be a thing), for example in the ppGTT
> insertion paths we should now be careful not to needlessly call
> make_unshrinkable multiple times. Outside of that there is some
> fallout
> in intel_context which relies on nesting calls to shrink_pin.
>
> Signed-off-by: Matthew Auld
> Cc: Thomas Hellström
Hmm. One thing that worries me a bit here: Let's say we have, for
example an LMEM context state, and TTM has it made unshrinkable. Then
the context becomes active and calls _make_unshrinkable again. And when
it retires it callse _make_shrinkable. Doesn't it end up on the
shrinker list at that point, even if still in LMEM?
/Thomas
Re: [PATCH] drm: document pre-multiplied assumptions
On Wed, Sep 29, 2021 at 09:54:14AM +, Simon Ser wrote: > When a plane is missing the "alpha blend mode" property, KMS drivers > will use the pre-multiplied mode. > > Signed-off-by: Simon Ser > Cc: Daniel Vetter > Cc: Pekka Paalanen Reviewed-by: Ville Syrjälä Another option would be to sprinkle immutable props to all drivers that claim to do alpha blending and don't currently expose the property. > --- > drivers/gpu/drm/drm_blend.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c > index ec37cbfabb50..eebb32ba84d7 100644 > --- a/drivers/gpu/drm/drm_blend.c > +++ b/drivers/gpu/drm/drm_blend.c > @@ -185,6 +185,9 @@ > *plane does not expose the "alpha" property, then this is > *assumed to be 1.0 > * > + * When a plane is missing this property, the plane uses the > + * "Pre-multiplied" equation. > + * > * Note that all the property extensions described here apply either to the > * plane or the CRTC (e.g. for the background color, which currently is not > * exposed and assumed to be black). > -- > 2.33.0 > -- Ville Syrjälä Intel
[PATCH] drm/msm: Fix null pointer dereference on pointer edp
From: Colin Ian King
The initialization of pointer dev dereferences pointer edp before
edp is null checked, so there is a potential null pointer deference
issue. Fix this by only dereferencing edp after edp has been null
checked.
Addresses-Coverity: ("Dereference before null check")
Fixes: ab5b0107ccf3 ("drm/msm: Initial add eDP support in msm drm driver (v5)")
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/msm/edp/edp_ctrl.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/edp/edp_ctrl.c
b/drivers/gpu/drm/msm/edp/edp_ctrl.c
index 4fb397ee7c84..fe1366b4c49f 100644
--- a/drivers/gpu/drm/msm/edp/edp_ctrl.c
+++ b/drivers/gpu/drm/msm/edp/edp_ctrl.c
@@ -1116,7 +1116,7 @@ void msm_edp_ctrl_power(struct edp_ctrl *ctrl, bool on)
int msm_edp_ctrl_init(struct msm_edp *edp)
{
struct edp_ctrl *ctrl = NULL;
- struct device *dev = >pdev->dev;
+ struct device *dev;
int ret;
if (!edp) {
@@ -1124,6 +1124,7 @@ int msm_edp_ctrl_init(struct msm_edp *edp)
return -EINVAL;
}
+ dev = >pdev->dev;
ctrl = devm_kzalloc(dev, sizeof(*ctrl), GFP_KERNEL);
if (!ctrl)
return -ENOMEM;
--
2.32.0
Re: [PATCH v8 09/12] media: mtk-vcodec: Get rid of mtk_smi_larb_get/put
On 29.09.21 03:37, Yong Wu wrote:
MediaTek IOMMU has already added the device_link between the consumer
and smi-larb device. If the vcodec device call the pm_runtime_get_sync,
the smi-larb's pm_runtime_get_sync also be called automatically.
CC: Tiffany Lin
CC: Irui Wang
Signed-off-by: Yong Wu
Reviewed-by: Evan Green
Acked-by: Tiffany Lin
Reviewed-by: Dafna Hirschfeld
---
.../platform/mtk-vcodec/mtk_vcodec_dec_pm.c | 37 +++-
.../platform/mtk-vcodec/mtk_vcodec_drv.h | 3 --
.../platform/mtk-vcodec/mtk_vcodec_enc.c | 1 -
.../platform/mtk-vcodec/mtk_vcodec_enc_pm.c | 44 +++
4 files changed, 10 insertions(+), 75 deletions(-)
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c
index 6038db96f71c..d0bf9aa3b29d 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c
@@ -8,14 +8,12 @@
#include
#include
#include
-#include
#include "mtk_vcodec_dec_pm.h"
#include "mtk_vcodec_util.h"
int mtk_vcodec_init_dec_pm(struct mtk_vcodec_dev *mtkdev)
{
- struct device_node *node;
struct platform_device *pdev;
struct mtk_vcodec_pm *pm;
struct mtk_vcodec_clk *dec_clk;
@@ -26,18 +24,7 @@ int mtk_vcodec_init_dec_pm(struct mtk_vcodec_dev *mtkdev)
pm = >pm;
pm->mtkdev = mtkdev;
dec_clk = >vdec_clk;
- node = of_parse_phandle(pdev->dev.of_node, "mediatek,larb", 0);
- if (!node) {
- mtk_v4l2_err("of_parse_phandle mediatek,larb fail!");
- return -1;
- }
- pdev = of_find_device_by_node(node);
- of_node_put(node);
- if (WARN_ON(!pdev)) {
- return -1;
- }
- pm->larbvdec = >dev;
pdev = mtkdev->plat_dev;
pm->dev = >dev;
@@ -47,14 +34,11 @@ int mtk_vcodec_init_dec_pm(struct mtk_vcodec_dev *mtkdev)
dec_clk->clk_info = devm_kcalloc(>dev,
dec_clk->clk_num, sizeof(*clk_info),
GFP_KERNEL);
- if (!dec_clk->clk_info) {
- ret = -ENOMEM;
- goto put_device;
- }
+ if (!dec_clk->clk_info)
+ return -ENOMEM;
} else {
mtk_v4l2_err("Failed to get vdec clock count");
- ret = -EINVAL;
- goto put_device;
+ return -EINVAL;
}
for (i = 0; i < dec_clk->clk_num; i++) {
@@ -63,29 +47,24 @@ int mtk_vcodec_init_dec_pm(struct mtk_vcodec_dev *mtkdev)
"clock-names", i, _info->clk_name);
if (ret) {
mtk_v4l2_err("Failed to get clock name id = %d", i);
- goto put_device;
+ return ret;
}
clk_info->vcodec_clk = devm_clk_get(>dev,
clk_info->clk_name);
if (IS_ERR(clk_info->vcodec_clk)) {
mtk_v4l2_err("devm_clk_get (%d)%s fail", i,
clk_info->clk_name);
- ret = PTR_ERR(clk_info->vcodec_clk);
- goto put_device;
+ return PTR_ERR(clk_info->vcodec_clk);
}
}
pm_runtime_enable(>dev);
return 0;
-put_device:
- put_device(pm->larbvdec);
- return ret;
}
void mtk_vcodec_release_dec_pm(struct mtk_vcodec_dev *dev)
{
pm_runtime_disable(dev->pm.dev);
- put_device(dev->pm.larbvdec);
}
Now that functions only do 'pm_runtime_disable(dev->pm.dev);' so it will be
more
readable to remove the function mtk_vcodec_release_dec_pm
and replace with pm_runtime_disable(dev->pm.dev);
Same for the 'enc' equivalent.
Thanks,
Dafna
int mtk_vcodec_dec_pw_on(struct mtk_vcodec_pm *pm)
@@ -122,11 +101,6 @@ void mtk_vcodec_dec_clock_on(struct mtk_vcodec_pm *pm)
}
}
- ret = mtk_smi_larb_get(pm->larbvdec);
- if (ret) {
- mtk_v4l2_err("mtk_smi_larb_get larbvdec fail %d", ret);
- goto error;
- }> return;
error:
@@ -139,7 +113,6 @@ void mtk_vcodec_dec_clock_off(struct mtk_vcodec_pm *pm)
struct mtk_vcodec_clk *dec_clk = >vdec_clk;
int i = 0;
- mtk_smi_larb_put(pm->larbvdec);
for (i = dec_clk->clk_num - 1; i >= 0; i--)
clk_disable_unprepare(dec_clk->clk_info[i].vcodec_clk);
}
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
index c6c7672fecfb..64b73dd880ce 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
@@ -189,10 +189,7 @@ struct mtk_vcodec_clk {
*/
struct mtk_vcodec_pm {
struct mtk_vcodec_clk vdec_clk;
- struct
Re: [Intel-gfx] [PATCH v5 01/13] drm/ttm: stop calling tt_swapin in vm_access
Am 27.09.21 um 18:14 schrieb Matthew Auld:
On Mon, 27 Sept 2021 at 12:47, Christian König wrote:
Any objections that I just push patches 1-7 to drm-misc-next?
Please go ahead Christian. Thanks.
Well I've pushed patches #1-#4 because #5 won't apply on current
drm-misc-next (some conflict in i915).
Could you rebase this an/or request backmerging of drm-next into
drm-misc-next when potential i915 prerequisites have landed there.
Thanks,
Christian.
Christian.
Am 27.09.21 um 13:41 schrieb Matthew Auld:
In commit:
commit 09ac4fcb3f255e9225967c75f5893325c116cdbe
Author: Felix Kuehling
Date: Thu Jul 13 17:01:16 2017 -0400
drm/ttm: Implement vm_operations_struct.access v2
we added the vm_access hook, where we also directly call tt_swapin for
some reason. If something is swapped-out then the ttm_tt must also be
unpopulated, and since access_kmap should also call tt_populate, if
needed, then swapping-in will already be handled there.
If anything, calling tt_swapin directly here would likely always fail
since the tt->pages won't yet be populated, or worse since the tt->pages
array is never actually cleared in unpopulate this might lead to a nasty
uaf.
Fixes: 09ac4fcb3f25 ("drm/ttm: Implement vm_operations_struct.access v2")
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Christian König
Reviewed-by: Thomas Hellström
Reviewed-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo_vm.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
index f56be5bc0861..5b9b7fd01a69 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
@@ -519,11 +519,6 @@ int ttm_bo_vm_access(struct vm_area_struct *vma, unsigned
long addr,
switch (bo->resource->mem_type) {
case TTM_PL_SYSTEM:
- if (unlikely(bo->ttm->page_flags & TTM_PAGE_FLAG_SWAPPED)) {
- ret = ttm_tt_swapin(bo->ttm);
- if (unlikely(ret != 0))
- return ret;
- }
fallthrough;
case TTM_PL_TT:
ret = ttm_bo_vm_access_kmap(bo, offset, buf, len, write);
Re: [PATCH v5 13/13] drm/i915/ttm: enable shmem tt backend
On Mon, 2021-09-27 at 12:41 +0100, Matthew Auld wrote:
> Turn on the shmem tt backend, and enable shrinking.
>
> Signed-off-by: Matthew Auld
> Cc: Thomas Hellström
> ---
> drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> index 46d57541c0b2..4ae630fbc5cd 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> @@ -1093,6 +1093,7 @@ static u64 i915_ttm_mmap_offset(struct
> drm_i915_gem_object *obj)
>
> static const struct drm_i915_gem_object_ops i915_gem_ttm_obj_ops = {
> .name = "i915_gem_object_ttm",
> + .flags = I915_GEM_OBJECT_IS_SHRINKABLE,
>
> .get_pages = i915_ttm_get_pages,
> .put_pages = i915_ttm_put_pages,
Reviewed-by: Thomas Hellström
Now that BAT is running a DG1 again, it might be worth to give the
series a rerun. Perhaps with the "rework object initialization
slightly" as a HAX patch to unblock the mman + following selftest.
/Thomas
Re: [PATCH v5 12/13] drm/i915/ttm: use cached system pages when evicting lmem
On Mon, 2021-09-27 at 12:41 +0100, Matthew Auld wrote:
> This should let us do an accelerated copy directly to the shmem pages
> when temporarily moving lmem-only objects, where the i915-gem
> shrinker
> can later kick in to swap out the pages, if needed.
>
> Signed-off-by: Matthew Auld
> Cc: Thomas Hellström
> ---
> drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 8
> 1 file changed, 4 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 194e5f1deda8..46d57541c0b2 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> @@ -134,11 +134,11 @@ static enum ttm_caching
> i915_ttm_select_tt_caching(const struct drm_i915_gem_object *obj)
> {
> /*
> - * Objects only allowed in system get cached cpu-mappings.
> - * Other objects get WC mapping for now. Even if in system.
> + * Objects only allowed in system get cached cpu-mappings, or
> when
> + * evicting lmem-only buffers to system for swapping. Other
> objects get
> + * WC mapping for now. Even if in system.
> */
> - if (obj->mm.region->type == INTEL_MEMORY_SYSTEM &&
> - obj->mm.n_placements <= 1)
> + if (obj->mm.n_placements <= 1)
> return ttm_cached;
>
> return ttm_write_combined;
We should be aware that with TTM, even evicted bos can be mapped by
user-space while evicted, and this will appear to user-space like the
WC-mapped object suddenly became WB-mapped. But it appears like mesa
doesn't care about this as long as the mappings are fully coherent.
Reviewed-by: Thomas Hellström
[PATCH][V2] drm/msm: Fix potential integer overflow on 32 bit multiply
From: Colin Ian King
In the case where clock is 2147485 or greater the 32 bit multiplication
by 1000 will cause an integer overflow. Fix this by making the constant
1000 an unsigned long to ensure a long multiply occurs to avoid the
overflow before assigning the result to the long result in variable
requested. Most probably a theoretical overflow issue, but worth fixing
to clear up static analysis warnings.
Addresses-Coverity: ("Unintentional integer overflow")
Fixes: c8afe684c95c ("drm/msm: basic KMS driver for snapdragon")
Fixes: 3e87599b68e7 ("drm/msm/mdp4: add LVDS panel support")
Fixes: 937f941ca06f ("drm/msm/dp: Use qmp phy for DP PLL and PHY")
Fixes: ab5b0107ccf3 ("drm/msm: Initial add eDP support in msm drm driver (v5)")
Fixes: a3376e3ec81c ("drm/msm: convert to drm_bridge")
Signed-off-by: Colin Ian King
---
V2: Find and fix all unintentional integer overflows that match this
overflow pattern.
---
drivers/gpu/drm/msm/disp/mdp4/mdp4_dtv_encoder.c| 2 +-
drivers/gpu/drm/msm/disp/mdp4/mdp4_lcdc_encoder.c | 2 +-
drivers/gpu/drm/msm/disp/mdp4/mdp4_lvds_connector.c | 2 +-
drivers/gpu/drm/msm/dp/dp_ctrl.c| 4 ++--
drivers/gpu/drm/msm/edp/edp_connector.c | 2 +-
drivers/gpu/drm/msm/hdmi/hdmi_bridge.c | 2 +-
drivers/gpu/drm/msm/hdmi/hdmi_connector.c | 2 +-
7 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/mdp4/mdp4_dtv_encoder.c
b/drivers/gpu/drm/msm/disp/mdp4/mdp4_dtv_encoder.c
index 88645dbc3785..83140066441e 100644
--- a/drivers/gpu/drm/msm/disp/mdp4/mdp4_dtv_encoder.c
+++ b/drivers/gpu/drm/msm/disp/mdp4/mdp4_dtv_encoder.c
@@ -50,7 +50,7 @@ static void mdp4_dtv_encoder_mode_set(struct drm_encoder
*encoder,
DBG("set mode: " DRM_MODE_FMT, DRM_MODE_ARG(mode));
- mdp4_dtv_encoder->pixclock = mode->clock * 1000;
+ mdp4_dtv_encoder->pixclock = mode->clock * 1000U;
DBG("pixclock=%lu", mdp4_dtv_encoder->pixclock);
diff --git a/drivers/gpu/drm/msm/disp/mdp4/mdp4_lcdc_encoder.c
b/drivers/gpu/drm/msm/disp/mdp4/mdp4_lcdc_encoder.c
index 10eb3e5b218e..d90dc0a39855 100644
--- a/drivers/gpu/drm/msm/disp/mdp4/mdp4_lcdc_encoder.c
+++ b/drivers/gpu/drm/msm/disp/mdp4/mdp4_lcdc_encoder.c
@@ -225,7 +225,7 @@ static void mdp4_lcdc_encoder_mode_set(struct drm_encoder
*encoder,
DBG("set mode: " DRM_MODE_FMT, DRM_MODE_ARG(mode));
- mdp4_lcdc_encoder->pixclock = mode->clock * 1000;
+ mdp4_lcdc_encoder->pixclock = mode->clock * 1000U;
DBG("pixclock=%lu", mdp4_lcdc_encoder->pixclock);
diff --git a/drivers/gpu/drm/msm/disp/mdp4/mdp4_lvds_connector.c
b/drivers/gpu/drm/msm/disp/mdp4/mdp4_lvds_connector.c
index 7288041dd86a..a965e7962a7f 100644
--- a/drivers/gpu/drm/msm/disp/mdp4/mdp4_lvds_connector.c
+++ b/drivers/gpu/drm/msm/disp/mdp4/mdp4_lvds_connector.c
@@ -64,7 +64,7 @@ static int mdp4_lvds_connector_mode_valid(struct
drm_connector *connector,
struct drm_encoder *encoder = mdp4_lvds_connector->encoder;
long actual, requested;
- requested = 1000 * mode->clock;
+ requested = 1000U * mode->clock;
actual = mdp4_lcdc_round_pixclk(encoder, requested);
DBG("requested=%ld, actual=%ld", requested, actual);
diff --git a/drivers/gpu/drm/msm/dp/dp_ctrl.c b/drivers/gpu/drm/msm/dp/dp_ctrl.c
index 62e75dc8afc6..6babeb79aeb0 100644
--- a/drivers/gpu/drm/msm/dp/dp_ctrl.c
+++ b/drivers/gpu/drm/msm/dp/dp_ctrl.c
@@ -1316,7 +1316,7 @@ static int dp_ctrl_enable_mainlink_clocks(struct
dp_ctrl_private *ctrl)
opts_dp->lanes = ctrl->link->link_params.num_lanes;
opts_dp->link_rate = ctrl->link->link_params.rate / 100;
dp_ctrl_set_clock_rate(ctrl, DP_CTRL_PM, "ctrl_link",
- ctrl->link->link_params.rate * 1000);
+ ctrl->link->link_params.rate * 1000U);
phy_configure(phy, _io->phy_opts);
phy_power_on(phy);
@@ -1336,7 +1336,7 @@ static int dp_ctrl_enable_stream_clocks(struct
dp_ctrl_private *ctrl)
int ret = 0;
dp_ctrl_set_clock_rate(ctrl, DP_STREAM_PM, "stream_pixel",
- ctrl->dp_ctrl.pixel_rate * 1000);
+ ctrl->dp_ctrl.pixel_rate * 1000U);
ret = dp_power_clk_enable(ctrl->power, DP_STREAM_PM, true);
if (ret)
diff --git a/drivers/gpu/drm/msm/edp/edp_connector.c
b/drivers/gpu/drm/msm/edp/edp_connector.c
index 73cb5fd97a5a..837e7873141f 100644
--- a/drivers/gpu/drm/msm/edp/edp_connector.c
+++ b/drivers/gpu/drm/msm/edp/edp_connector.c
@@ -64,7 +64,7 @@ static int edp_connector_mode_valid(struct drm_connector
*connector,
struct msm_kms *kms = priv->kms;
long actual, requested;
- requested = 1000 * mode->clock;
+ requested = 1000L * mode->clock;
actual = kms->funcs->round_pixclk(kms,
requested, edp_connector->edp->encoder);
diff --git
Re: [PATCH v5 11/13] drm/i915/ttm: make evicted shmem pages visible to the shrinker
On Mon, 2021-09-27 at 12:41 +0100, Matthew Auld wrote:
> We currently just evict lmem objects to system memory when under
> memory
> pressure, and in the next patch we want to use the shmem backend even
> for this case. For this case we lack the usual object mm.pages, which
> effectively hides the pages from the i915-gem shrinker, until we
> actually "attach" the TT to the object, or in the case of lmem-only
> objects it just gets migrated back to lmem when touched again.
>
> For all cases we can just adjust the i915 shrinker LRU each time we
> also
> adjust the TTM LRU. The two cases we care about are:
>
> 1) When something is moved by TTM, including when initially
> populating
> an object. Importantly this covers the case where TTM moves
> something from
> lmem <-> smem, outside of the normal get_pages() interface,
> which
> should still ensure the shmem pages underneath are reclaimable.
>
> 2) When calling into i915_gem_object_unlock(). The unlock should
> ensure the object is removed from the shinker LRU, if it was
> indeed
> swapped out, or just purged, when the shrinker drops the object
> lock.
>
> We can optimise this(if needed) by tracking if the object is already
> visible to the shrinker(protected by the object lock), so we don't
> touch
> the shrinker LRU more than needed.
>
> v2(Thomas)
> - Handle managing the shrinker LRU in adjust_lru, where it is
> always
> safe to touch the object.
>
> Signed-off-by: Matthew Auld
> Cc: Thomas Hellström
> ---
> drivers/gpu/drm/i915/gem/i915_gem_object.h | 1 +
> drivers/gpu/drm/i915/gem/i915_gem_shrinker.c | 29 +++---
> --
> drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 28 +++---
> -
> 3 files changed, 46 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h
> b/drivers/gpu/drm/i915/gem/i915_gem_object.h
> index 1c9a1d8d3434..640dfbf1f01e 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
> @@ -523,6 +523,7 @@ i915_gem_object_pin_to_display_plane(struct
> drm_i915_gem_object *obj,
>
> void i915_gem_object_make_unshrinkable(struct drm_i915_gem_object
> *obj);
> void i915_gem_object_make_shrinkable(struct drm_i915_gem_object
> *obj);
> +void __i915_gem_object_make_shrinkable(struct drm_i915_gem_object
> *obj);
> void i915_gem_object_make_purgeable(struct drm_i915_gem_object
> *obj);
>
> static inline bool cpu_write_needs_clflush(struct
> drm_i915_gem_object *obj)
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
> b/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
> index 0440696f786a..4b6b2bb6f180 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
> @@ -487,13 +487,12 @@ void i915_gem_object_make_unshrinkable(struct
> drm_i915_gem_object *obj)
> spin_unlock_irqrestore(>mm.obj_lock, flags);
> }
>
> -static void __i915_gem_object_make_shrinkable(struct
> drm_i915_gem_object *obj,
> - struct list_head *head)
> +static void ___i915_gem_object_make_shrinkable(struct
> drm_i915_gem_object *obj,
> + struct list_head
> *head)
> {
> struct drm_i915_private *i915 = obj_to_i915(obj);
> unsigned long flags;
>
> - GEM_BUG_ON(!i915_gem_object_has_pages(obj));
> if (!i915_gem_object_is_shrinkable(obj))
> return;
>
> @@ -512,6 +511,21 @@ static void
> __i915_gem_object_make_shrinkable(struct drm_i915_gem_object *obj,
> spin_unlock_irqrestore(>mm.obj_lock, flags);
> }
>
> +/**
> + * __i915_gem_object_make_shrinkable - Move the object to the tail
> of the
> + * shrinkable list. Objects on this list might be swapped out. Used
> with
> + * WILLNEED objects.
> + * @obj: The GEM object.
> + *
> + * DO NOT USE. This is intended to be called on very special objects
> that don't
> + * yet have mm.pages, but are guaranteed to have potentially
> reclaimable pages
> + * underneath.
> + */
> +void __i915_gem_object_make_shrinkable(struct drm_i915_gem_object
> *obj)
> +{
> + ___i915_gem_object_make_shrinkable(obj,
> + _to_i915(obj)-
> >mm.shrink_list);
> +}
>
> /**
> * i915_gem_object_make_shrinkable - Move the object to the tail of
> the
> @@ -523,8 +537,8 @@ static void
> __i915_gem_object_make_shrinkable(struct drm_i915_gem_object *obj,
> */
> void i915_gem_object_make_shrinkable(struct drm_i915_gem_object
> *obj)
> {
> - __i915_gem_object_make_shrinkable(obj,
> - _to_i915(obj)-
> >mm.shrink_list);
> + GEM_BUG_ON(!i915_gem_object_has_pages(obj));
> + __i915_gem_object_make_shrinkable(obj);
> }
>
> /**
> @@ -538,6 +552,7 @@ void i915_gem_object_make_shrinkable(struct
> drm_i915_gem_object *obj)
> */
> void i915_gem_object_make_purgeable(struct drm_i915_gem_object
NAK: [PATCH] drm/msm/mdp4: Fix potential integer overflow on 32 bit multiply
On 29/09/2021 12:08, Colin King wrote:
From: Colin Ian King
In the case where clock is 2147485 or greater the 32 bit multiplication
by 1000 will cause an integer overflow. Fix this by making the constant
1000 a long to ensure a long multiply occurs to avoid the overflow
before assigning the result to the long result in variable requested.
Most probably a theoretical overflow issue, but worth fixing.
Addresses-Coverity: ("Unintentional integer overflow")
Fixes: 3e87599b68e7 ("drm/msm/mdp4: add LVDS panel support")
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/msm/disp/mdp4/mdp4_lvds_connector.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/disp/mdp4/mdp4_lvds_connector.c
b/drivers/gpu/drm/msm/disp/mdp4/mdp4_lvds_connector.c
index 7288041dd86a..deada745d5b9 100644
--- a/drivers/gpu/drm/msm/disp/mdp4/mdp4_lvds_connector.c
+++ b/drivers/gpu/drm/msm/disp/mdp4/mdp4_lvds_connector.c
@@ -64,7 +64,7 @@ static int mdp4_lvds_connector_mode_valid(struct
drm_connector *connector,
struct drm_encoder *encoder = mdp4_lvds_connector->encoder;
long actual, requested;
- requested = 1000 * mode->clock;
+ requested = 1000L * mode->clock;
actual = mdp4_lcdc_round_pixclk(encoder, requested);
DBG("requested=%ld, actual=%ld", requested, actual);
NACK: there are a few more occurrences of this in the msm driver, I'll
fix them up for a V2.
Re: [PATCH] drm/atomic: Add the crtc to affected crtc only if uapi.enable = true
On Thu, Apr 01, 2021 at 02:49:13PM -0700, Navare, Manasi wrote:
> On Fri, Mar 26, 2021 at 06:15:22PM +0200, Ville Syrjälä wrote:
> > On Thu, Mar 25, 2021 at 03:01:29PM -0700, Navare, Manasi wrote:
> > > On Fri, Mar 19, 2021 at 11:27:59PM +0200, Ville Syrjälä wrote:
> > > > On Fri, Mar 19, 2021 at 02:26:24PM -0700, Navare, Manasi wrote:
> > > > > On Fri, Mar 19, 2021 at 11:12:41PM +0200, Ville Syrjälä wrote:
> > > > > > On Fri, Mar 19, 2021 at 01:54:13PM -0700, Navare, Manasi wrote:
> > > > > > > On Fri, Mar 19, 2021 at 04:56:24PM +0200, Ville Syrjälä wrote:
> > > > > > > > On Thu, Mar 18, 2021 at 04:01:26PM -0700, Navare, Manasi wrote:
> > > > > > > > > So basically we see this warning only in case of bigjoiner
> > > > > > > > > when
> > > > > > > > > drm_atomic_check gets called without setting the
> > > > > > > > > state->allow_modeset flag.
> > > > > > > >
> > > > > > > > Considering the code is 'WARN(!state->allow_modeset, ...' that
> > > > > > > > fact should be rather obvious.
> > > > > > > >
> > > > > > > > >
> > > > > > > > > So do you think that in i915, in
> > > > > > > > > intel_atomic_check_bigjoiner() we should only
> > > > > > > > > steal the crtc when allow_modeset flag is set in state?
> > > > > > > >
> > > > > > > > No. If you fully read drm_atomic_check_only() you will observe
> > > > > > > > that it will reject any commit w/ allow_modeset==false which
> > > > > > > > needs a modeset. And it does that before the WARN.
> > > > > > > >
> > > > > > > > So you're barking up the wrong tree here. The problem I think
> > > > > > > > is that you're just computing requested_crtcs wrong.
> > > > > > >
> > > > > > > So here in this case, requested CRTC = 0x1 since it requests
> > > > > > > modeset on CRTC 0
> > > > > > > Now in teh atomic check, it steals the slave CRTC 1 and hence
> > > > > > > affected CRTC comes out
> > > > > > > as 0x3 and hence the mismatch.
> > > > > >
> > > > > > Hmm. How can it be 0x3 if we filtered out the uapi.enable==false
> > > > > > case?
> > > > > >
> > > > >
> > > > > Yes if I add that condition like in this patch then it correctly
> > > > > calculates
> > > > > the affected crtc bitmask as only 0x1 since it doesnt include the
> > > > > slave crtc.
> > > > > So with this patch, requested crtc = 0x 1, affected crtc = 0x1
> > > > >
> > > > > If this looks good then this fixes our bigjoiner warnings.
> > > > > Does this patch look good to you as is then?
> > > >
> > > > I think you still need to fix the requested_crtcs calculation.
> > >
> > > We calculate requested crtc at the beginning :
> > > for_each_new_crtc_in_state(state, crtc, new_crtc_state, i)
> > > requested_crtc |= drm_crtc_mask(crtc);
> > >
> > > Are you suggesting adding this to after:
> > > if (config->funcs->atomic_check) {
> > > ret = config->funcs->atomic_check(state->dev, state);
> > >
> > > if (ret) {
> > > DRM_DEBUG_ATOMIC("atomic driver check for %p
> > > failed: %d\n",
> > > state, ret);
> > > return ret;
> > > }
> > > requested_crtc |= drm_crtc_mask(crtc);// Here it will have
> > > requested crtc = 0x11
> > > }
> > >
> > > in this case here the state should already have master crtc 0 and slave
> > > crtc 1
> > > and that requested crtc should already be 0x11
> > >
> > > Then in that case we dont need any special check for calculating affected
> > > crtc, that also will be 0x11
> >
> > All I'm saying is that you're currently calculating requested_crtcs and
> > affected_crtcs differently. So I'm not at all surprised that they might
> > not match.
> >
>
> I dont get your point yet.
> requested crtc is calculated before the atomic check call and we dont check
> for crtc uapi.enable to be true.
> And hence requested crtc = CRTC 0 = 0x2
> After I added the check in this patch where affected crtc will include only
> the crtcs that have uapi.enable = true
> then it perfectly matches the requested crtc and return 0x2 but without this
> check when the calculation of
> requested and affected crtc is the same is where we see the affected crtc =
> CRTC 0 and 1 = 0x3
>
> So when the calculation is different infcat we dont see the mismatch
>
> What is your point here?
Try doing an atomic commit wiht both crtcs already added in by
userspace. I think that will still WARN.
--
Ville Syrjälä
Intel
