Re: [PATCH v5 23/36] drm/bridge: analogix_dp: Move fast link training detect to set_bridge
On Saturday 10 March 2018 03:53 AM, Enric Balletbo i Serra wrote:
From: zain wang
It's too early to detect fast link training, if other step after it
failed, we will set fast_link flag to 1, and retry set_bridge again. In
this case we will power down and power up panel power supply, and we
will do fast link training since we have set fast_link flag to 1. In
fact, we should do full link training now, not the fast link training.
So we should move the fast link detection at the end of set_bridge.
Is it possible to re-write this commit message? It's a bit hard to
follow.
Thanks,
Archit
Cc: Tomasz Figa
Signed-off-by: zain wang
Signed-off-by: Douglas Anderson
Signed-off-by: Sean Paul
Signed-off-by: Thierry Escande
Reviewed-by: Andrzej Hajda
Signed-off-by: Enric Balletbo i Serra
Tested-by: Marek Szyprowski
---
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 42 +-
1 file changed, 26 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index d76e1652b1fd..37b16643f14c 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -601,7 +601,7 @@ static int analogix_dp_process_equalizer_training(struct
analogix_dp_device *dp)
{
int lane, lane_count, retval;
u32 reg;
- u8 link_align, link_status[2], adjust_request[2], spread;
+ u8 link_align, link_status[2], adjust_request[2];
usleep_range(400, 401);
@@ -645,20 +645,6 @@ static int analogix_dp_process_equalizer_training(struct analogix_dp_device *dp)
dev_dbg(dp->dev, "final lane count = %.2x\n",
dp->link_train.lane_count);
- retval = drm_dp_dpcd_readb(&dp->aux, DP_MAX_DOWNSPREAD,
- &spread);
- if (retval != 1) {
- dev_err(dp->dev, "failed to read downspread %d\n",
- retval);
- dp->fast_train_enable = false;
- } else {
- dp->fast_train_enable =
- (spread & DP_NO_AUX_HANDSHAKE_LINK_TRAINING) ?
- true : false;
- }
- dev_dbg(dp->dev, "fast link training %s\n",
- dp->fast_train_enable ? "supported" : "unsupported");
-
dp->link_train.lt_state = FINISHED;
return 0;
@@ -996,6 +982,22 @@ static irqreturn_t analogix_dp_irq_thread(int irq, void
*arg)
return IRQ_HANDLED;
}
+static int analogix_dp_fast_link_train_detection(struct analogix_dp_device *dp)
+{
+ int ret;
+ u8 spread;
+
+ ret = drm_dp_dpcd_readb(&dp->aux, DP_MAX_DOWNSPREAD, &spread);
+ if (ret != 1) {
+ dev_err(dp->dev, "failed to read downspread %d\n", ret);
+ return ret;
+ }
+ dp->fast_train_enable = !!(spread & DP_NO_AUX_HANDSHAKE_LINK_TRAINING);
+ dev_dbg(dp->dev, "fast link training %s\n",
+ dp->fast_train_enable ? "supported" : "unsupported");
+ return 0;
+}
+
static int analogix_dp_commit(struct analogix_dp_device *dp)
{
int ret;
@@ -1038,8 +1040,16 @@ static int analogix_dp_commit(struct analogix_dp_device
*dp)
if (ret)
return ret;
- if (dp->psr_enable)
+ if (dp->psr_enable) {
ret = analogix_dp_enable_sink_psr(dp);
+ if (ret)
+ return ret;
+ }
+
+ /* Check whether panel supports fast training */
+ ret = analogix_dp_fast_link_train_detection(dp);
+ if (ret)
+ dp->psr_enable = false;
return ret;
}
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 24/36] drm/bridge: analogix_dp: Reorder plat_data->power_off to happen sooner
On Saturday 10 March 2018 03:53 AM, Enric Balletbo i Serra wrote: From: Douglas Anderson The current user of the analogix power_off is "analogix_dp-rockchip". That driver does this: - deactivate PSR - turn off a clock Both of these things (especially deactive PSR) should be done before we turn the PHY power off and turn off analog power. Let's move the callback up. Note that without this patch (and with https://patchwork.kernel.org/patch/9553349/ [seanpaul: this patch was not applied, but it seems like the race can still occur]), I experienced an error in reboot testing where one thread was at: rockchip_drm_psr_deactivate rockchip_dp_powerdown analogix_dp_bridge_disable drm_bridge_disable ...and the other thread was at: analogix_dp_send_psr_spd analogix_dp_enable_psr analogix_dp_psr_set psr_flush_handler The flush handler thread was finding AUX channel errors and eventually reported "Failed to apply PSR", where I had a kgdb breakpoint. Presumably the device would have eventually given up and shut down anyway, but it seems better to fix the order to be more correct. Reviewed-by: Archit Taneja Thanks, Archit Cc: Kristian H. Kristensen Signed-off-by: Douglas Anderson Signed-off-by: Sean Paul Signed-off-by: Thierry Escande Reviewed-by: Andrzej Hajda Signed-off-by: Enric Balletbo i Serra Tested-by: Marek Szyprowski --- drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c index 37b16643f14c..eaf93cbd47a8 100644 --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c @@ -1337,12 +1337,13 @@ static void analogix_dp_bridge_disable(struct drm_bridge *bridge) } disable_irq(dp->irq); - analogix_dp_set_analog_power_down(dp, POWER_ALL, 1); - phy_power_off(dp->phy); if (dp->plat_data->power_off) dp->plat_data->power_off(dp->plat_data); + analogix_dp_set_analog_power_down(dp, POWER_ALL, 1); + phy_power_off(dp->phy); + clk_disable_unprepare(dp->clock); pm_runtime_put_sync(dp->dev); ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 25/36] drm/bridge: analogix_dp: Properly log AUX CH errors
On Saturday 10 March 2018 03:53 AM, Enric Balletbo i Serra wrote:
From: Douglas Anderson
The code in analogix_dp_transfer() that was supposed to print out:
AUX CH error happened
Was actually dead code. That's because the previous check (whether
the interrupt status indicated any errors) would have hit for all
errors anyway.
Let's combine the two error checks so we can actually see AUX CH
errors. We'll also downgrade the message to a warning since some of
these types of errors might be expected for some displays. If this
gets too noisy we can downgrade again to debug.
Reviewed-by: Archit Taneja
Thanks,
Archit
Cc: 征增 王
Signed-off-by: Douglas Anderson
Signed-off-by: Sean Paul
Signed-off-by: Thierry Escande
Reviewed-by: Andrzej Hajda
Signed-off-by: Enric Balletbo i Serra
Tested-by: Marek Szyprowski
---
drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
index 4eae206ec31b..58e8a28e99aa 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
@@ -1105,6 +1105,7 @@ ssize_t analogix_dp_transfer(struct analogix_dp_device
*dp,
struct drm_dp_aux_msg *msg)
{
u32 reg;
+ u32 status_reg;
u8 *buffer = msg->buffer;
unsigned int i;
int num_transferred = 0;
@@ -1193,16 +1194,12 @@ ssize_t analogix_dp_transfer(struct analogix_dp_device
*dp,
/* Clear interrupt source for AUX CH access error */
reg = readl(dp->reg_base + ANALOGIX_DP_INT_STA);
- if (reg & AUX_ERR) {
+ status_reg = readl(dp->reg_base + ANALOGIX_DP_AUX_CH_STA);
+ if ((reg & AUX_ERR) || (status_reg & AUX_STATUS_MASK)) {
writel(AUX_ERR, dp->reg_base + ANALOGIX_DP_INT_STA);
- goto aux_error;
- }
- /* Check AUX CH error access status */
- reg = readl(dp->reg_base + ANALOGIX_DP_AUX_CH_STA);
- if ((reg & AUX_STATUS_MASK)) {
- dev_err(dp->dev, "AUX CH error happened: %d\n\n",
- reg & AUX_STATUS_MASK);
+ dev_warn(dp->dev, "AUX CH error happened: %#x (%d)\n",
+status_reg & AUX_STATUS_MASK, !!(reg & AUX_ERR));
goto aux_error;
}
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 26/36] drm/bridge: analogix_dp: Properly disable aux chan retries on rockchip
On Saturday 10 March 2018 03:53 AM, Enric Balletbo i Serra wrote: From: Douglas Anderson The comments in analogix_dp_init_aux() claim that we're disabling aux channel retries, but then right below it for Rockchip it sets them to 3. If we actually need 3 retries for Rockchip then we could adjust the comment, but it seems more likely that we want the same retry behavior across all platforms. Reviewed-by: Archit Taneja Thanks, Archit Cc: Stéphane Marchesin Cc: 征增 王 Signed-off-by: Douglas Anderson Signed-off-by: Sean Paul Signed-off-by: Thierry Escande Signed-off-by: Enric Balletbo i Serra Tested-by: Marek Szyprowski --- drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 15 --- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c index 58e8a28e99aa..a5f2763d72e4 100644 --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c @@ -481,15 +481,16 @@ void analogix_dp_init_aux(struct analogix_dp_device *dp) analogix_dp_reset_aux(dp); - /* Disable AUX transaction H/W retry */ + /* AUX_BIT_PERIOD_EXPECTED_DELAY doesn't apply to Rockchip IP */ if (dp->plat_data && is_rockchip(dp->plat_data->dev_type)) - reg = AUX_BIT_PERIOD_EXPECTED_DELAY(0) | - AUX_HW_RETRY_COUNT_SEL(3) | - AUX_HW_RETRY_INTERVAL_600_MICROSECONDS; + reg = 0; else - reg = AUX_BIT_PERIOD_EXPECTED_DELAY(3) | - AUX_HW_RETRY_COUNT_SEL(0) | - AUX_HW_RETRY_INTERVAL_600_MICROSECONDS; + reg = AUX_BIT_PERIOD_EXPECTED_DELAY(3); + + /* Disable AUX transaction H/W retry */ + reg |= AUX_HW_RETRY_COUNT_SEL(0) | + AUX_HW_RETRY_INTERVAL_600_MICROSECONDS; + writel(reg, dp->reg_base + ANALOGIX_DP_AUX_HW_RETRY_CTL); /* Receive AUX Channel DEFER commands equal to DEFFER_COUNT*64 */ ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
linux-next: merge conflict between drm-misc and sound trees
Dear Stephen,
when rebuilding linux-next you're going to see a merge conflict in:
sound/pci/hda/hda_intel.c
betwen commit:
1ba8f9d30817 ("ALSA: hda: Add a power_save blacklist")
from the sound tree and commit:
07f4f97d7b4b ("vga_switcheroo: Use device link for HDA controller")
from the drm-misc tree.
I recommend fixing it up like below.
-- >8 --
@@@ -2284,16 -2298,22 +2303,30 @@@
chip->running = 1;
azx_add_card_list(chip);
+ /*
+ * The discrete GPU cannot power down unless the HDA controller runtime
+ * suspends, so activate runtime PM on codecs even if power_save == 0.
+ */
+ if (use_vga_switcheroo(hda))
+ list_for_each_codec(codec, &chip->bus)
+ codec->auto_runtime_pm = 1;
+
- snd_hda_set_power_save(&chip->bus, power_save * 1000);
+ val = power_save;
+ #ifdef CONFIG_PM
+ if (val == -1) {
+ const struct snd_pci_quirk *q;
+
+ val = CONFIG_SND_HDA_POWER_SAVE_DEFAULT;
+ q = snd_pci_quirk_lookup(chip->pci, power_save_blacklist);
+ if (q && val) {
+ dev_info(chip->card->dev, "device %04x:%04x is on the
power_save blacklist, forcing power_save to 0\n",
+q->subvendor, q->subdevice);
+ val = 0;
+ }
+ }
+ #endif /* CONFIG_PM */
+ snd_hda_set_power_save(&chip->bus, val * 1000);
- if (azx_has_pm_runtime(chip) || hda->use_vga_switcheroo)
+ if (azx_has_pm_runtime(chip))
pm_runtime_put_autosuspend(&pci->dev);
out_free:
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 22/36] drm/bridge: analogix_dp: Fix incorrect operations with register ANALOGIX_DP_FUNC_EN_1
On Saturday 10 March 2018 03:53 AM, Enric Balletbo i Serra wrote:
From: zain wang
Register ANALOGIX_DP_FUNC_EN_1(offset 0x18), Rockchip is different to
Exynos:
on Exynos edp phy,
BIT 7 MASTER_VID_FUNC_EN_N
BIT 6 reserved
BIT 5 SLAVE_VID_FUNC_EN_N
on Rockchip edp phy,
BIT 7 reserved
BIT 6 RK_VID_CAP_FUNC_EN_N
BIT 5 RK_VID_FIFO_FUNC_EN_N
So, we should do some private operations to Rockchip.
Reviewed-by: Archit Taneja
Thanks,
Archit
Cc: Tomasz Figa
Signed-off-by: zain wang
Signed-off-by: Sean Paul
Signed-off-by: Thierry Escande
Reviewed-by: Andrzej Hajda
Signed-off-by: Enric Balletbo i Serra
Tested-by: Marek Szyprowski
---
drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 19 ++-
drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h | 2 ++
2 files changed, 16 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
index 02ab1aaa9993..4eae206ec31b 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
@@ -126,9 +126,14 @@ void analogix_dp_reset(struct analogix_dp_device *dp)
analogix_dp_stop_video(dp);
analogix_dp_enable_video_mute(dp, 0);
- reg = MASTER_VID_FUNC_EN_N | SLAVE_VID_FUNC_EN_N |
- AUD_FIFO_FUNC_EN_N | AUD_FUNC_EN_N |
- HDCP_FUNC_EN_N | SW_FUNC_EN_N;
+ if (dp->plat_data && is_rockchip(dp->plat_data->dev_type))
+ reg = RK_VID_CAP_FUNC_EN_N | RK_VID_FIFO_FUNC_EN_N |
+ SW_FUNC_EN_N;
+ else
+ reg = MASTER_VID_FUNC_EN_N | SLAVE_VID_FUNC_EN_N |
+ AUD_FIFO_FUNC_EN_N | AUD_FUNC_EN_N |
+ HDCP_FUNC_EN_N | SW_FUNC_EN_N;
+
writel(reg, dp->reg_base + ANALOGIX_DP_FUNC_EN_1);
reg = SSC_FUNC_EN_N | AUX_FUNC_EN_N |
@@ -971,8 +976,12 @@ void analogix_dp_config_video_slave_mode(struct
analogix_dp_device *dp)
u32 reg;
reg = readl(dp->reg_base + ANALOGIX_DP_FUNC_EN_1);
- reg &= ~(MASTER_VID_FUNC_EN_N | SLAVE_VID_FUNC_EN_N);
- reg |= MASTER_VID_FUNC_EN_N;
+ if (dp->plat_data && is_rockchip(dp->plat_data->dev_type)) {
+ reg &= ~(RK_VID_CAP_FUNC_EN_N | RK_VID_FIFO_FUNC_EN_N);
+ } else {
+ reg &= ~(MASTER_VID_FUNC_EN_N | SLAVE_VID_FUNC_EN_N);
+ reg |= MASTER_VID_FUNC_EN_N;
+ }
writel(reg, dp->reg_base + ANALOGIX_DP_FUNC_EN_1);
reg = readl(dp->reg_base + ANALOGIX_DP_VIDEO_CTL_10);
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h
b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h
index b633a4a5082a..0cf27c731727 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h
@@ -127,7 +127,9 @@
/* ANALOGIX_DP_FUNC_EN_1 */
#define MASTER_VID_FUNC_EN_N (0x1 << 7)
+#define RK_VID_CAP_FUNC_EN_N (0x1 << 6)
#define SLAVE_VID_FUNC_EN_N (0x1 << 5)
+#define RK_VID_FIFO_FUNC_EN_N (0x1 << 5)
#define AUD_FIFO_FUNC_EN_N(0x1 << 4)
#define AUD_FUNC_EN_N (0x1 << 3)
#define HDCP_FUNC_EN_N(0x1 << 2)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 20/36] drm/bridge: analogix_dp: Don't use ANALOGIX_DP_PLL_CTL to control pll
On Saturday 10 March 2018 03:53 AM, Enric Balletbo i Serra wrote:
From: zain wang
There is no register named ANALOGIX_DP_PLL_CTL in Rockchip edp phy reg
list. We should use BIT_4 in ANALOGIX_DP_PD to control the pll power
instead of ANALOGIX_DP_PLL_CTL.
Reviewed-by: Archit Taneja
Thanks,
Archit
Cc: Douglas Anderson
Signed-off-by: zain wang
Signed-off-by: Sean Paul
Signed-off-by: Thierry Escande
Reviewed-by: Andrzej Hajda
Signed-off-by: Enric Balletbo i Serra
Tested-by: Marek Szyprowski
---
drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 20
1 file changed, 12 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
index 7b7fd227e1f9..02ab1aaa9993 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
@@ -230,16 +230,20 @@ enum pll_status analogix_dp_get_pll_lock_status(struct
analogix_dp_device *dp)
void analogix_dp_set_pll_power_down(struct analogix_dp_device *dp, bool
enable)
{
u32 reg;
+ u32 mask = DP_PLL_PD;
+ u32 pd_addr = ANALOGIX_DP_PLL_CTL;
- if (enable) {
- reg = readl(dp->reg_base + ANALOGIX_DP_PLL_CTL);
- reg |= DP_PLL_PD;
- writel(reg, dp->reg_base + ANALOGIX_DP_PLL_CTL);
- } else {
- reg = readl(dp->reg_base + ANALOGIX_DP_PLL_CTL);
- reg &= ~DP_PLL_PD;
- writel(reg, dp->reg_base + ANALOGIX_DP_PLL_CTL);
+ if (dp->plat_data && is_rockchip(dp->plat_data->dev_type)) {
+ pd_addr = ANALOGIX_DP_PD;
+ mask = RK_PLL_PD;
}
+
+ reg = readl(dp->reg_base + pd_addr);
+ if (enable)
+ reg |= mask;
+ else
+ reg &= ~mask;
+ writel(reg, dp->reg_base + pd_addr);
}
void analogix_dp_set_analog_power_down(struct analogix_dp_device *dp,
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 19/36] drm/rockchip: Restore psr->state when enable/disable psr failed
On Saturday 10 March 2018 03:53 AM, Enric Balletbo i Serra wrote:
From: zain wang
If we failed disable psr, it would hang the display until next psr
cycle coming. So we should restore psr->state when it failed.
For the bridge part,
Reviewed-by: Archit Taneja
Thanks,
Archit
Cc: Tomasz Figa
Signed-off-by: zain wang
Signed-off-by: Douglas Anderson
Signed-off-by: Sean Paul
Signed-off-by: Thierry Escande
Signed-off-by: Enric Balletbo i Serra
Tested-by: Marek Szyprowski
---
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 4 +++-
drivers/gpu/drm/rockchip/analogix_dp-rockchip.c| 10 +-
drivers/gpu/drm/rockchip/rockchip_drm_psr.c| 20 +---
drivers/gpu/drm/rockchip/rockchip_drm_psr.h| 2 +-
4 files changed, 22 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index be6eddd0d0a7..1f1cb624414d 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -153,8 +153,10 @@ int analogix_dp_disable_psr(struct analogix_dp_device *dp)
psr_vsc.DB1 = 0;
ret = drm_dp_dpcd_writeb(&dp->aux, DP_SET_POWER, DP_SET_POWER_D0);
- if (ret != 1)
+ if (ret != 1) {
dev_err(dp->dev, "Failed to set DP Power0 %d\n", ret);
+ return ret;
+ }
return analogix_dp_send_psr_spd(dp, &psr_vsc, false);
}
diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index 3e8bf79bea58..8c884f9ce713 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -77,13 +77,13 @@ struct rockchip_dp_device {
struct analogix_dp_plat_data plat_data;
};
-static void analogix_dp_psr_set(struct drm_encoder *encoder, bool enabled)
+static int analogix_dp_psr_set(struct drm_encoder *encoder, bool enabled)
{
struct rockchip_dp_device *dp = to_dp(encoder);
int ret;
if (!analogix_dp_psr_enabled(dp->adp))
- return;
+ return 0;
DRM_DEV_DEBUG(dp->dev, "%s PSR...\n", enabled ? "Entry" : "Exit");
@@ -91,13 +91,13 @@ static void analogix_dp_psr_set(struct drm_encoder *encoder, bool enabled)
PSR_WAIT_LINE_FLAG_TIMEOUT_MS);
if (ret) {
DRM_DEV_ERROR(dp->dev, "line flag interrupt did not arrive\n");
- return;
+ return -ETIMEDOUT;
}
if (enabled)
- analogix_dp_enable_psr(dp->adp);
+ return analogix_dp_enable_psr(dp->adp);
else
- analogix_dp_disable_psr(dp->adp);
+ return analogix_dp_disable_psr(dp->adp);
}
static int rockchip_dp_pre_init(struct rockchip_dp_device *dp)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
b/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
index b339ca943139..9376f4396b6b 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
@@ -36,7 +36,7 @@ struct psr_drv {
struct delayed_work flush_work;
- void (*set)(struct drm_encoder *encoder, bool enable);
+ int (*set)(struct drm_encoder *encoder, bool enable);
};
static struct psr_drv *find_psr_by_crtc(struct drm_crtc *crtc)
@@ -93,19 +93,25 @@ static void psr_set_state_locked(struct psr_drv *psr, enum
psr_state state)
return;
}
- psr->state = state;
-
/* Actually commit the state change to hardware */
- switch (psr->state) {
+ switch (state) {
case PSR_ENABLE:
- psr->set(psr->encoder, true);
+ if (psr->set(psr->encoder, true))
+ return;
break;
case PSR_DISABLE:
case PSR_FLUSH:
- psr->set(psr->encoder, false);
+ if (psr->set(psr->encoder, false))
+ return;
break;
+
+ default:
+ pr_err("%s: Unknown state %d\n", __func__, state);
+ return;
}
+
+ psr->state = state;
}
static void psr_set_state(struct psr_drv *psr, enum psr_state state)
@@ -229,7 +235,7 @@ EXPORT_SYMBOL(rockchip_drm_psr_flush_all);
* Zero on success, negative errno on failure.
*/
int rockchip_drm_psr_register(struct drm_encoder *encoder,
- void (*psr_set)(struct drm_encoder *, bool enable))
+ int (*psr_set)(struct drm_encoder *, bool enable))
{
struct rockchip_drm_private *drm_drv = encoder->dev->dev_private;
struct psr_drv *psr;
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_psr.h
b/drivers/gpu/drm/rockchip/rockchip_drm_psr.h
index b1ea0155e57c..06537ee27565 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_psr.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_psr.h
@@ -22,7 +22
Re: [PATCH v5 18/36] drm/bridge: analogix_dp: Reset aux channel if an error occurred
On Saturday 10 March 2018 03:53 AM, Enric Balletbo i Serra wrote:
From: Lin Huang
AUX errors are caused by many different reasons. We may not know what
happened in aux channel on failure, so let's reset aux channel if some
errors occurred.
Cc: 征增 王
Cc: Douglas Anderson
Signed-off-by: Lin Huang
Signed-off-by: Sean Paul
Signed-off-by: Thierry Escande
Reviewed-by: Andrzej Hajda
Tested-by: Marek Szyprowski
Signed-off-by: Enric Balletbo i Serra
---
drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 18 ++
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
index dee1ba109b5f..7b7fd227e1f9 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
@@ -466,6 +466,10 @@ void analogix_dp_init_aux(struct analogix_dp_device *dp)
reg = RPLY_RECEIV | AUX_ERR;
writel(reg, dp->reg_base + ANALOGIX_DP_INT_STA);
+ analogix_dp_set_analog_power_down(dp, AUX_BLOCK, true);
+ usleep_range(10, 11);
+ analogix_dp_set_analog_power_down(dp, AUX_BLOCK, false);
+
Is this additional power on/off the analog power to the AUX block
required to reset it correctly? If so, could you mention that in the
commit message?
analogix_dp_reset_aux(dp);
/* Disable AUX transaction H/W retry */
@@ -1159,7 +1163,7 @@ ssize_t analogix_dp_transfer(struct analogix_dp_device
*dp,
reg, !(reg & AUX_EN), 25, 500 * 1000);
if (ret) {
dev_err(dp->dev, "AUX CH enable timeout!\n");
- return -ETIMEDOUT;
+ goto aux_error;
}
/* TODO: Wait for an interrupt instead of looping? */
@@ -1168,7 +1172,7 @@ ssize_t analogix_dp_transfer(struct analogix_dp_device
*dp,
reg, reg & RPLY_RECEIV, 10, 20 * 1000);
if (ret) {
dev_err(dp->dev, "AUX CH cmd reply timeout!\n");
- return -ETIMEDOUT;
+ goto aux_error;
}
/* Clear interrupt source for AUX CH command reply */
@@ -1178,7 +1182,7 @@ ssize_t analogix_dp_transfer(struct analogix_dp_device
*dp,
reg = readl(dp->reg_base + ANALOGIX_DP_INT_STA);
if (reg & AUX_ERR) {
writel(AUX_ERR, dp->reg_base + ANALOGIX_DP_INT_STA);
- return -EREMOTEIO;
+ goto aux_error;
}
/* Check AUX CH error access status */
@@ -1186,7 +1190,7 @@ ssize_t analogix_dp_transfer(struct analogix_dp_device
*dp,
if ((reg & AUX_STATUS_MASK)) {
dev_err(dp->dev, "AUX CH error happened: %d\n\n",
reg & AUX_STATUS_MASK);
- return -EREMOTEIO;
+ goto aux_error;
}
if (msg->request & DP_AUX_I2C_READ) {
@@ -1212,4 +1216,10 @@ ssize_t analogix_dp_transfer(struct analogix_dp_device
*dp,
msg->reply = DP_AUX_NATIVE_REPLY_ACK;
return num_transferred > 0 ? num_transferred : -EBUSY;
+
+aux_error:
+ /* if aux err happen, reset aux */
+ analogix_dp_init_aux(dp);
+
+ return -EREMOTEIO;
A couple of ETIMEDOUTs have been replaced with EREMOTEIOs after this
change. Maybe we set it the error no in ret and return ret?
With those changes,
Reviewed-by: Archit Taneja
Thanks,
Archit
}
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 17/36] drm/bridge: analogix_dp: Fix AUX_PD bit for Rockchip
On Saturday 10 March 2018 03:53 AM, Enric Balletbo i Serra wrote:
From: zain wang
There are some different bits between Rockchip and Exynos in register
"AUX_PD". This patch fixes the incorrect operations about it.
You mean the register ANALOGIX_DP_PHY_PD/ANALOGIX_DP_PD, right? AUX_PD
sounds like just one of the fields of the register.
With that,
Reviewed-by: Archit Taneja
Thanks,
Archit
Cc: Douglas Anderson
Signed-off-by: zain wang
Signed-off-by: Sean Paul
Signed-off-by: Thierry Escande
Reviewed-by: Andrzej Hajda
Signed-off-by: Enric Balletbo i Serra
Tested-by: Marek Szyprowski
---
drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 117 --
drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h | 2 +
2 files changed, 65 insertions(+), 54 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
index bb72f8b0e603..dee1ba109b5f 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
@@ -248,76 +248,85 @@ void analogix_dp_set_analog_power_down(struct
analogix_dp_device *dp,
{
u32 reg;
u32 phy_pd_addr = ANALOGIX_DP_PHY_PD;
+ u32 mask;
if (dp->plat_data && is_rockchip(dp->plat_data->dev_type))
phy_pd_addr = ANALOGIX_DP_PD;
switch (block) {
case AUX_BLOCK:
- if (enable) {
- reg = readl(dp->reg_base + phy_pd_addr);
- reg |= AUX_PD;
- writel(reg, dp->reg_base + phy_pd_addr);
- } else {
- reg = readl(dp->reg_base + phy_pd_addr);
- reg &= ~AUX_PD;
- writel(reg, dp->reg_base + phy_pd_addr);
- }
+ if (dp->plat_data && is_rockchip(dp->plat_data->dev_type))
+ mask = RK_AUX_PD;
+ else
+ mask = AUX_PD;
+
+ reg = readl(dp->reg_base + phy_pd_addr);
+ if (enable)
+ reg |= mask;
+ else
+ reg &= ~mask;
+ writel(reg, dp->reg_base + phy_pd_addr);
break;
case CH0_BLOCK:
- if (enable) {
- reg = readl(dp->reg_base + phy_pd_addr);
- reg |= CH0_PD;
- writel(reg, dp->reg_base + phy_pd_addr);
- } else {
- reg = readl(dp->reg_base + phy_pd_addr);
- reg &= ~CH0_PD;
- writel(reg, dp->reg_base + phy_pd_addr);
- }
+ mask = CH0_PD;
+ reg = readl(dp->reg_base + phy_pd_addr);
+
+ if (enable)
+ reg |= mask;
+ else
+ reg &= ~mask;
+ writel(reg, dp->reg_base + phy_pd_addr);
break;
case CH1_BLOCK:
- if (enable) {
- reg = readl(dp->reg_base + phy_pd_addr);
- reg |= CH1_PD;
- writel(reg, dp->reg_base + phy_pd_addr);
- } else {
- reg = readl(dp->reg_base + phy_pd_addr);
- reg &= ~CH1_PD;
- writel(reg, dp->reg_base + phy_pd_addr);
- }
+ mask = CH1_PD;
+ reg = readl(dp->reg_base + phy_pd_addr);
+
+ if (enable)
+ reg |= mask;
+ else
+ reg &= ~mask;
+ writel(reg, dp->reg_base + phy_pd_addr);
break;
case CH2_BLOCK:
- if (enable) {
- reg = readl(dp->reg_base + phy_pd_addr);
- reg |= CH2_PD;
- writel(reg, dp->reg_base + phy_pd_addr);
- } else {
- reg = readl(dp->reg_base + phy_pd_addr);
- reg &= ~CH2_PD;
- writel(reg, dp->reg_base + phy_pd_addr);
- }
+ mask = CH2_PD;
+ reg = readl(dp->reg_base + phy_pd_addr);
+
+ if (enable)
+ reg |= mask;
+ else
+ reg &= ~mask;
+ writel(reg, dp->reg_base + phy_pd_addr);
break;
case CH3_BLOCK:
- if (enable) {
- reg = readl(dp->reg_base + phy_pd_addr);
- reg |= CH3_PD;
- writel(reg, dp->reg_base + phy_pd_addr);
- } else {
- reg = readl(dp->reg_base + phy_pd_addr);
- reg &= ~CH3_PD;
- writel(reg, dp->reg_base + phy_pd_addr);
- }
+ mask = CH3_PD;
+ reg = readl(dp->reg_base + phy_pd_addr);
+
+ if
Re: [PATCH v5 16/36] drm/bridge: analogix_dp: Check dpcd write/read status
On Saturday 10 March 2018 03:53 AM, Enric Balletbo i Serra wrote:
From: Lin Huang
We need to check the dpcd write/read return value to see whether the
write/read was successful
Reviewed-by: Archit Taneja
Thanks,
Archit
Cc: Kristian H. Kristensen
Signed-off-by: Lin Huang
Signed-off-by: zain wang
Signed-off-by: Douglas Anderson
Signed-off-by: Sean Paul
Signed-off-by: Thierry Escande
Reviewed-by: Andrzej Hajda
Signed-off-by: Enric Balletbo i Serra
Tested-by: Marek Szyprowski
---
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 169 -
1 file changed, 127 insertions(+), 42 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 1eed35f9eb8d..be6eddd0d0a7 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -160,80 +160,137 @@ int analogix_dp_disable_psr(struct analogix_dp_device
*dp)
}
EXPORT_SYMBOL_GPL(analogix_dp_disable_psr);
-static bool analogix_dp_detect_sink_psr(struct analogix_dp_device *dp)
+static int analogix_dp_detect_sink_psr(struct analogix_dp_device *dp)
{
unsigned char psr_version;
+ int ret;
+
+ ret = drm_dp_dpcd_readb(&dp->aux, DP_PSR_SUPPORT, &psr_version);
+ if (ret != 1) {
+ dev_err(dp->dev, "failed to get PSR version, disable it\n");
+ return ret;
+ }
- drm_dp_dpcd_readb(&dp->aux, DP_PSR_SUPPORT, &psr_version);
dev_dbg(dp->dev, "Panel PSR version : %x\n", psr_version);
- return (psr_version & DP_PSR_IS_SUPPORTED) ? true : false;
+ dp->psr_enable = (psr_version & DP_PSR_IS_SUPPORTED) ? true : false;
+
+ return 0;
}
-static void analogix_dp_enable_sink_psr(struct analogix_dp_device *dp)
+static int analogix_dp_enable_sink_psr(struct analogix_dp_device *dp)
{
unsigned char psr_en;
+ int ret;
/* Disable psr function */
- drm_dp_dpcd_readb(&dp->aux, DP_PSR_EN_CFG, &psr_en);
+ ret = drm_dp_dpcd_readb(&dp->aux, DP_PSR_EN_CFG, &psr_en);
+ if (ret != 1) {
+ dev_err(dp->dev, "failed to get psr config\n");
+ goto end;
+ }
+
psr_en &= ~DP_PSR_ENABLE;
- drm_dp_dpcd_writeb(&dp->aux, DP_PSR_EN_CFG, psr_en);
+ ret = drm_dp_dpcd_writeb(&dp->aux, DP_PSR_EN_CFG, psr_en);
+ if (ret != 1) {
+ dev_err(dp->dev, "failed to disable panel psr\n");
+ goto end;
+ }
/* Main-Link transmitter remains active during PSR active states */
psr_en = DP_PSR_MAIN_LINK_ACTIVE | DP_PSR_CRC_VERIFICATION;
- drm_dp_dpcd_writeb(&dp->aux, DP_PSR_EN_CFG, psr_en);
+ ret = drm_dp_dpcd_writeb(&dp->aux, DP_PSR_EN_CFG, psr_en);
+ if (ret != 1) {
+ dev_err(dp->dev, "failed to set panel psr\n");
+ goto end;
+ }
/* Enable psr function */
psr_en = DP_PSR_ENABLE | DP_PSR_MAIN_LINK_ACTIVE |
DP_PSR_CRC_VERIFICATION;
- drm_dp_dpcd_writeb(&dp->aux, DP_PSR_EN_CFG, psr_en);
+ ret = drm_dp_dpcd_writeb(&dp->aux, DP_PSR_EN_CFG, psr_en);
+ if (ret != 1) {
+ dev_err(dp->dev, "failed to set panel psr\n");
+ goto end;
+ }
analogix_dp_enable_psr_crc(dp);
+
+ return 0;
+end:
+ dev_err(dp->dev, "enable psr fail, force to disable psr\n");
+ dp->psr_enable = false;
+
+ return ret;
}
-static void
+static int
analogix_dp_enable_rx_to_enhanced_mode(struct analogix_dp_device *dp,
bool enable)
{
u8 data;
+ int ret;
- drm_dp_dpcd_readb(&dp->aux, DP_LANE_COUNT_SET, &data);
+ ret = drm_dp_dpcd_readb(&dp->aux, DP_LANE_COUNT_SET, &data);
+ if (ret != 1)
+ return ret;
if (enable)
- drm_dp_dpcd_writeb(&dp->aux, DP_LANE_COUNT_SET,
- DP_LANE_COUNT_ENHANCED_FRAME_EN |
- DPCD_LANE_COUNT_SET(data));
+ ret = drm_dp_dpcd_writeb(&dp->aux, DP_LANE_COUNT_SET,
+DP_LANE_COUNT_ENHANCED_FRAME_EN |
+DPCD_LANE_COUNT_SET(data));
else
- drm_dp_dpcd_writeb(&dp->aux, DP_LANE_COUNT_SET,
- DPCD_LANE_COUNT_SET(data));
+ ret = drm_dp_dpcd_writeb(&dp->aux, DP_LANE_COUNT_SET,
+DPCD_LANE_COUNT_SET(data));
+
+ return ret < 0 ? ret : 0;
}
-static int analogix_dp_is_enhanced_mode_available(struct analogix_dp_device *dp)
+static int analogix_dp_is_enhanced_mode_available(struct analogix_dp_device
*dp,
+ u8 *enhanced_mode_support)
{
u8 data;
- int retval;
+ int ret;
- drm_dp_dpcd_readb(&dp->aux, DP_MAX_LANE_COUNT, &data);
-
Re: [PATCH v5 15/36] drm/bridge: analogix_dp: Fix incorrect usage of enhanced mode
On Saturday 10 March 2018 03:53 AM, Enric Balletbo i Serra wrote: From: zain wang Enhanced mode is required by the eDP 1.2 specification, and not doing it early could result in a period of time where we have a link transmitting idle packets without it. Since there is no reason to disable it, we just enable it at the beginning of link training and then keep it on all the time. Reviewed-by: Archit Taneja Thanks, Archit Cc: Tomasz Figa Signed-off-by: zain wang Signed-off-by: Sean Paul Signed-off-by: Thierry Escande Reviewed-by: Andrzej Hajda Signed-off-by: Enric Balletbo i Serra Tested-by: Marek Szyprowski --- drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c index 6cbde8473f58..1eed35f9eb8d 100644 --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c @@ -281,6 +281,8 @@ static int analogix_dp_link_start(struct analogix_dp_device *dp) retval = drm_dp_dpcd_write(&dp->aux, DP_LINK_BW_SET, buf, 2); if (retval < 0) return retval; + /* set enhanced mode if available */ + analogix_dp_set_enhanced_mode(dp); /* Set TX pre-emphasis to minimum */ for (lane = 0; lane < lane_count; lane++) @@ -593,8 +595,6 @@ static int analogix_dp_process_equalizer_training(struct analogix_dp_device *dp) dev_dbg(dp->dev, "fast link training %s\n", dp->fast_train_enable ? "supported" : "unsupported"); - /* set enhanced mode if available */ - analogix_dp_set_enhanced_mode(dp); dp->link_train.lt_state = FINISHED; return 0; @@ -940,8 +940,6 @@ static int analogix_dp_commit(struct analogix_dp_device *dp) } analogix_dp_enable_scramble(dp, 1); - analogix_dp_enable_rx_to_enhanced_mode(dp, 1); - analogix_dp_enable_enhanced_mode(dp, 1); analogix_dp_init_video(dp); ret = analogix_dp_config_video(dp); ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 14/36] drm/bridge: analogix_dp: Extend hpd check time to 100ms
On Saturday 10 March 2018 03:53 AM, Enric Balletbo i Serra wrote: From: Lin Huang There was a 1ms delay to detect the hpd signal, which is too short to detect a short pulse. This patch extends this delay to 100ms. Reviewed-by: Archit Taneja Thanks, Archit Cc: Stéphane Marchesin Cc: 征增 王 Signed-off-by: Lin Huang Signed-off-by: Sean Paul Signed-off-by: Thierry Escande Reviewed-by: Andrzej Hajda Signed-off-by: Enric Balletbo i Serra Tested-by: Marek Szyprowski --- drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 2 +- 1 file changed, 1 insertion(+), 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 3a222e7e46ee..6cbde8473f58 100644 --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c @@ -76,7 +76,7 @@ static int analogix_dp_detect_hpd(struct analogix_dp_device *dp) return 0; timeout_loop++; - usleep_range(10, 11); + usleep_range(1000, 1100); } /* ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 13/36] drm/bridge: analogix_dp: Ensure edp is disabled when shutting down the panel
On Saturday 10 March 2018 03:53 AM, Enric Balletbo i Serra wrote:
From: Lin Huang
When panel is shut down, we should make sure edp can be disabled to avoid
undefined behavior.
Reviewed-by: Archit Taneja
Thanks,
Archit
Cc: Stéphane Marchesin
Signed-off-by: Lin Huang
Signed-off-by: zain wang
Signed-off-by: Sean Paul
Signed-off-by: Thierry Escande
Reviewed-by: Andrzej Hajda
Signed-off-by: Enric Balletbo i Serra
Tested-by: Marek Szyprowski
---
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 92fb9a072cb6..3a222e7e46ee 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -1160,6 +1160,12 @@ static int analogix_dp_set_bridge(struct
analogix_dp_device *dp)
pm_runtime_get_sync(dp->dev);
+ ret = clk_prepare_enable(dp->clock);
+ if (ret < 0) {
+ DRM_ERROR("Failed to prepare_enable the clock clk [%d]\n", ret);
+ goto out_dp_clk_pre;
+ }
+
if (dp->plat_data->power_on)
dp->plat_data->power_on(dp->plat_data);
@@ -1191,6 +1197,8 @@ static int analogix_dp_set_bridge(struct analogix_dp_device *dp)
phy_power_off(dp->phy);
if (dp->plat_data->power_off)
dp->plat_data->power_off(dp->plat_data);
+ clk_disable_unprepare(dp->clock);
+out_dp_clk_pre:
pm_runtime_put_sync(dp->dev);
return ret;
@@ -1233,11 +1241,14 @@ static void analogix_dp_bridge_disable(struct
drm_bridge *bridge)
}
disable_irq(dp->irq);
+ analogix_dp_set_analog_power_down(dp, POWER_ALL, 1);
phy_power_off(dp->phy);
if (dp->plat_data->power_off)
dp->plat_data->power_off(dp->plat_data);
+ clk_disable_unprepare(dp->clock);
+
pm_runtime_put_sync(dp->dev);
ret = analogix_dp_prepare_panel(dp, false, true);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 12/36] drm/bridge: analogix_dp: Set PD_INC_BG first when powering up edp phy
On Saturday 10 March 2018 03:53 AM, Enric Balletbo i Serra wrote:
From: zain wang
Following the correct power up sequence:
dp_pd=ff => dp_pd=7f => wait 10us => dp_pd=00
Reviewed-by: Archit Taneja
Thanks,
Archit
Cc: Stéphane Marchesin
Signed-off-by: zain wang
Signed-off-by: Sean Paul
Signed-off-by: Thierry Escande
Signed-off-by: Enric Balletbo i Serra
Tested-by: Marek Szyprowski
---
drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 10 --
drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h | 3 +++
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
index b47c5af43560..bb72f8b0e603 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
@@ -321,10 +321,16 @@ void analogix_dp_set_analog_power_down(struct
analogix_dp_device *dp,
break;
case POWER_ALL:
if (enable) {
- reg = DP_PHY_PD | AUX_PD | CH3_PD | CH2_PD |
- CH1_PD | CH0_PD;
+ reg = DP_ALL_PD;
writel(reg, dp->reg_base + phy_pd_addr);
} else {
+ reg = DP_ALL_PD;
+ writel(reg, dp->reg_base + phy_pd_addr);
+ usleep_range(10, 15);
+ reg &= ~DP_INC_BG;
+ writel(reg, dp->reg_base + phy_pd_addr);
+ usleep_range(10, 15);
+
writel(0x00, dp->reg_base + phy_pd_addr);
}
break;
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h
b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h
index 40200c652533..9602668669f4 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h
@@ -342,12 +342,15 @@
#define DP_PLL_REF_BIT_1_2500V(0x7 << 0)
/* ANALOGIX_DP_PHY_PD */
+#define DP_INC_BG (0x1 << 7)
+#define DP_EXP_BG (0x1 << 6)
#define DP_PHY_PD (0x1 << 5)
#define AUX_PD(0x1 << 4)
#define CH3_PD(0x1 << 3)
#define CH2_PD(0x1 << 2)
#define CH1_PD(0x1 << 1)
#define CH0_PD(0x1 << 0)
+#define DP_ALL_PD (0xff)
/* ANALOGIX_DP_PHY_TEST */
#define MACRO_RST (0x1 << 5)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 11/36] drm/bridge: analogix_dp: Wait for HPD signal before configuring link
On Saturday 10 March 2018 03:53 AM, Enric Balletbo i Serra wrote:
From: zain wang
According to DP spec v1.3 chap 3.5.1.2 Link Training, Link Policy Maker
must first detect that the HPD signal is asserted high by the Downstream
Device before establishing a link with it.
Reviewed-by: Archit Taneja
Thanks,
Archit
Cc: Stéphane Marchesin
Signed-off-by: zain wang
Signed-off-by: Sean Paul
Signed-off-by: Thierry Escande
Signed-off-by: Enric Balletbo i Serra
Tested-by: Marek Szyprowski
---
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index c81733b8185e..92fb9a072cb6 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -1169,6 +1169,17 @@ static int analogix_dp_set_bridge(struct
analogix_dp_device *dp)
if (ret)
goto out_dp_init;
+ /*
+* According to DP spec v1.3 chap 3.5.1.2 Link Training,
+* We should first make sure the HPD signal is asserted high by device
+* when we want to establish a link with it.
+*/
+ ret = analogix_dp_detect_hpd(dp);
+ if (ret) {
+ DRM_ERROR("failed to get hpd single ret = %d\n", ret);
+ goto out_dp_init;
+ }
+
ret = analogix_dp_commit(dp);
if (ret)
goto out_dp_init;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 10/36] drm/bridge: analogix_dp: Retry bridge enable when it failed
On Saturday 10 March 2018 03:53 AM, Enric Balletbo i Serra wrote:
From: zain wang
When we enable bridge failed, we have to retry it, otherwise we would get
the abnormal display.
Reviewed-by: Archit Taneja
Thanks,
Archit
Cc: Stéphane Marchesin
Signed-off-by: zain wang
Signed-off-by: Sean Paul
Signed-off-by: Thierry Escande
Reviewed-by: Andrzej Hajda
Signed-off-by: Enric Balletbo i Serra
Tested-by: Marek Szyprowski
---
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 65 +-
drivers/gpu/drm/bridge/analogix/analogix_dp_core.h | 3 +-
drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 5 +-
3 files changed, 56 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index ea7a80a989c6..c81733b8185e 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -43,8 +43,10 @@ struct bridge_init {
struct device_node *node;
};
-static void analogix_dp_init_dp(struct analogix_dp_device *dp)
+static int analogix_dp_init_dp(struct analogix_dp_device *dp)
{
+ int ret;
+
analogix_dp_reset(dp);
analogix_dp_swreset(dp);
@@ -56,10 +58,13 @@ static void analogix_dp_init_dp(struct analogix_dp_device
*dp)
analogix_dp_enable_sw_function(dp);
analogix_dp_config_interrupt(dp);
- analogix_dp_init_analog_func(dp);
+ ret = analogix_dp_init_analog_func(dp);
+ if (ret)
+ return ret;
analogix_dp_init_hpd(dp);
analogix_dp_init_aux(dp);
+ return 0;
}
static int analogix_dp_detect_hpd(struct analogix_dp_device *dp)
@@ -918,7 +923,7 @@ static irqreturn_t analogix_dp_irq_thread(int irq, void
*arg)
return IRQ_HANDLED;
}
-static void analogix_dp_commit(struct analogix_dp_device *dp)
+static int analogix_dp_commit(struct analogix_dp_device *dp)
{
int ret;
@@ -928,11 +933,10 @@ static void analogix_dp_commit(struct analogix_dp_device *dp)
DRM_ERROR("failed to disable the panel\n");
}
- ret = readx_poll_timeout(analogix_dp_train_link, dp, ret, !ret, 100,
-DP_TIMEOUT_TRAINING_US * 5);
+ ret = analogix_dp_train_link(dp);
if (ret) {
dev_err(dp->dev, "unable to do link train, ret=%d\n", ret);
- return;
+ return ret;
}
analogix_dp_enable_scramble(dp, 1);
@@ -953,6 +957,7 @@ static void analogix_dp_commit(struct analogix_dp_device
*dp)
dp->psr_enable = analogix_dp_detect_sink_psr(dp);
if (dp->psr_enable)
analogix_dp_enable_sink_psr(dp);
+ return 0;
}
/*
@@ -1149,12 +1154,9 @@ static void analogix_dp_bridge_pre_enable(struct
drm_bridge *bridge)
DRM_ERROR("failed to setup the panel ret = %d\n", ret);
}
-static void analogix_dp_bridge_enable(struct drm_bridge *bridge)
+static int analogix_dp_set_bridge(struct analogix_dp_device *dp)
{
- struct analogix_dp_device *dp = bridge->driver_private;
-
- if (dp->dpms_mode == DRM_MODE_DPMS_ON)
- return;
+ int ret;
pm_runtime_get_sync(dp->dev);
@@ -1162,11 +1164,46 @@ static void analogix_dp_bridge_enable(struct drm_bridge *bridge)
dp->plat_data->power_on(dp->plat_data);
phy_power_on(dp->phy);
- analogix_dp_init_dp(dp);
+
+ ret = analogix_dp_init_dp(dp);
+ if (ret)
+ goto out_dp_init;
+
+ ret = analogix_dp_commit(dp);
+ if (ret)
+ goto out_dp_init;
+
enable_irq(dp->irq);
- analogix_dp_commit(dp);
+ return 0;
- dp->dpms_mode = DRM_MODE_DPMS_ON;
+out_dp_init:
+ phy_power_off(dp->phy);
+ if (dp->plat_data->power_off)
+ dp->plat_data->power_off(dp->plat_data);
+ pm_runtime_put_sync(dp->dev);
+
+ return ret;
+}
+
+static void analogix_dp_bridge_enable(struct drm_bridge *bridge)
+{
+ struct analogix_dp_device *dp = bridge->driver_private;
+ int timeout_loop = 0;
+
+ if (dp->dpms_mode == DRM_MODE_DPMS_ON)
+ return;
+
+ while (timeout_loop < MAX_PLL_LOCK_LOOP) {
+ if (analogix_dp_set_bridge(dp) == 0) {
+ dp->dpms_mode = DRM_MODE_DPMS_ON;
+ return;
+ }
+ dev_err(dp->dev, "failed to set bridge, retry: %d\n",
+ timeout_loop);
+ timeout_loop++;
+ usleep_range(10, 11);
+ }
+ dev_err(dp->dev, "too many times retry set bridge, give it up\n");
}
static void analogix_dp_bridge_disable(struct drm_bridge *bridge)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
index 403ff853464b..769255dc6e99 100644
--- a/drivers/gpu/drm/bridge/analogix/
Re: [PATCH v2 0/7] Modernize vga_switcheroo by using device link for HDA
On Sun, Mar 11, 2018 at 04:55:49PM +0100, Lukas Wunner wrote: > > On Sat, Mar 03, 2018 at 10:53:24AM +0100, Lukas Wunner wrote: > > > Modernize vga_switcheroo by using a device link to enforce a runtime PM > > > dependency from an HDA controller to the GPU it's integrated into, v2. > > > > > > https://github.com/l1k/linux/commits/switcheroo_devlink_v2 > > If there are no objections, I plan to push the series to > drm-misc-next by the middle of the coming week so that it > would still catch the last train to 4.17. Pushed to drm-misc-next now with Bjorn's changelog tweak and ack for patch [1/1]. Thanks a lot everyone for the reviews, acks, testing & comments. Lukas ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 09/36] drm/bridge: analogix_dp: Don't use fast link training when panel just powered up
On Saturday 10 March 2018 03:53 AM, Enric Balletbo i Serra wrote:
From: zain wang
Panel would reset its setting when it powers down. It would forget the last
succeeded link training setting. So we can't use the last successful link
training setting to do fast link training. Let's reset fast_train_enable in
analogix_dp_bridge_disable();
Reviewed-by: Archit Taneja
Thanks,
Archit
Cc: Stéphane Marchesin
Signed-off-by: zain wang
Signed-off-by: Sean Paul
Signed-off-by: Thierry Escande
Signed-off-by: Enric Balletbo i Serra
Tested-by: Marek Szyprowski
---
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 9 +
drivers/gpu/drm/bridge/analogix/analogix_dp_core.h | 2 +-
2 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index f9661b410cb9..ea7a80a989c6 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -579,14 +579,14 @@ static int analogix_dp_process_equalizer_training(struct
analogix_dp_device *dp)
if (retval != 1) {
dev_err(dp->dev, "failed to read downspread %d\n",
retval);
- dp->fast_train_support = false;
+ dp->fast_train_enable = false;
} else {
- dp->fast_train_support =
+ dp->fast_train_enable =
(spread & DP_NO_AUX_HANDSHAKE_LINK_TRAINING) ?
true : false;
}
dev_dbg(dp->dev, "fast link training %s\n",
- dp->fast_train_support ? "supported" : "unsupported");
+ dp->fast_train_enable ? "supported" : "unsupported");
/* set enhanced mode if available */
analogix_dp_set_enhanced_mode(dp);
@@ -793,7 +793,7 @@ static int analogix_dp_fast_link_train(struct
analogix_dp_device *dp)
static int analogix_dp_train_link(struct analogix_dp_device *dp)
{
- if (dp->fast_train_support)
+ if (dp->fast_train_enable)
return analogix_dp_fast_link_train(dp);
return analogix_dp_full_link_train(dp, dp->video_info.max_lane_count,
@@ -1197,6 +1197,7 @@ static void analogix_dp_bridge_disable(struct drm_bridge
*bridge)
DRM_ERROR("failed to setup the panel ret = %d\n", ret);
dp->psr_enable = false;
+ dp->fast_train_enable = false;
dp->dpms_mode = DRM_MODE_DPMS_OFF;
}
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
index 6a96ef7e6934..403ff853464b 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
@@ -173,7 +173,7 @@ struct analogix_dp_device {
int hpd_gpio;
boolforce_hpd;
boolpsr_enable;
- boolfast_train_support;
+ boolfast_train_enable;
struct mutex panel_lock;
boolpanel_is_modeset;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 08/36] drm/bridge: analogix_dp: Check AUX_EN status when doing AUX transfer
On Saturday 10 March 2018 03:52 AM, Enric Balletbo i Serra wrote:
From: Lin Huang
We should check AUX_EN bit to confirm the AUX CH operation is completed.
Reviewed-by: Archit Taneja
Thanks,
Archit
Cc: Stéphane Marchesin
Signed-off-by: Lin Huang
Signed-off-by: zain wang
Signed-off-by: Sean Paul
Signed-off-by: Thierry Escande
Signed-off-by: Enric Balletbo i Serra
Tested-by: Marek Szyprowski
---
drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 25 +--
1 file changed, 14 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
index 9df2f3ef000c..e78c861b9e06 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
@@ -1073,9 +1073,9 @@ ssize_t analogix_dp_transfer(struct analogix_dp_device
*dp,
{
u32 reg;
u8 *buffer = msg->buffer;
- int timeout_loop = 0;
unsigned int i;
int num_transferred = 0;
+ int ret;
/* Buffer size of AUX CH is 16 bytes */
if (WARN_ON(msg->size > 16))
@@ -1139,17 +1139,20 @@ ssize_t analogix_dp_transfer(struct analogix_dp_device
*dp,
writel(reg, dp->reg_base + ANALOGIX_DP_AUX_CH_CTL_2);
- /* Is AUX CH command reply received? */
+ ret = readx_poll_timeout(readl, dp->reg_base + ANALOGIX_DP_AUX_CH_CTL_2,
+reg, !(reg & AUX_EN), 25, 500 * 1000);
+ if (ret) {
+ dev_err(dp->dev, "AUX CH enable timeout!\n");
+ return -ETIMEDOUT;
+ }
+
/* TODO: Wait for an interrupt instead of looping? */
- reg = readl(dp->reg_base + ANALOGIX_DP_INT_STA);
- while (!(reg & RPLY_RECEIV)) {
- timeout_loop++;
- if (timeout_loop > DP_TIMEOUT_LOOP_COUNT) {
- dev_err(dp->dev, "AUX CH command reply failed!\n");
- return -ETIMEDOUT;
- }
- reg = readl(dp->reg_base + ANALOGIX_DP_INT_STA);
- usleep_range(10, 11);
+ /* Is AUX CH command reply received? */
+ ret = readx_poll_timeout(readl, dp->reg_base + ANALOGIX_DP_INT_STA,
+reg, reg & RPLY_RECEIV, 10, 20 * 1000);
+ if (ret) {
+ dev_err(dp->dev, "AUX CH cmd reply timeout!\n");
+ return -ETIMEDOUT;
}
/* Clear interrupt source for AUX CH command reply */
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 07/36] drm/bridge: analogix_dp: Move enable video into config_video()
On Saturday 10 March 2018 03:52 AM, Enric Balletbo i Serra wrote:
From: Lin Huang
We need to enable video before analogix_dp_is_video_stream_on(), so
we can get the right video stream status.
Cc: 征增 王
Cc: Stéphane Marchesin
Signed-off-by: Lin Huang
Signed-off-by: Sean Paul
Signed-off-by: Thierry Escande
Reviewed-by: Andrzej Hajda
Signed-off-by: Enric Balletbo i Serra
Tested-by: Marek Szyprowski
---
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 5a2e35dc41e3..f9661b410cb9 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -819,11 +819,10 @@ static int analogix_dp_config_video(struct
analogix_dp_device *dp)
if (analogix_dp_is_slave_video_stream_clock_on(dp) == 0)
break;
if (timeout_loop > DP_TIMEOUT_LOOP_COUNT) {
- dev_err(dp->dev, "Timeout of video streamclk ok\n");
+ dev_err(dp->dev, "Timeout of slave video streamclk
ok\n");
return -ETIMEDOUT;
}
-
- usleep_range(1, 2);
+ usleep_range(1000, 1001);
Could we briefly explain in the commit message why we need to increase
the delay in the timeout loop? Is it a consequence of calling
analogix_dp_start_video() earlier, or is this the preferred time
mentioned in the specs?
Thanks,
Archit
}
/* Set to use the register calculated M/N video */
@@ -838,6 +837,9 @@ static int analogix_dp_config_video(struct
analogix_dp_device *dp)
/* Configure video slave mode */
analogix_dp_enable_video_master(dp, 0);
+ /* Enable video */
+ analogix_dp_start_video(dp);
+
timeout_loop = 0;
for (;;) {
@@ -948,9 +950,6 @@ static void analogix_dp_commit(struct analogix_dp_device
*dp)
DRM_ERROR("failed to enable the panel\n");
}
- /* Enable video */
- analogix_dp_start_video(dp);
-
dp->psr_enable = analogix_dp_detect_sink_psr(dp);
if (dp->psr_enable)
analogix_dp_enable_sink_psr(dp);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 06/36] drm/rockchip: Only wait for panel ACK on PSR entry
On Saturday 10 March 2018 03:52 AM, Enric Balletbo i Serra wrote:
From: zain wang
We currently wait for the panel to mirror our intended PSR state
before continuing on both PSR enter and PSR exit. This is really
only important to do when we're entering PSR, since we want to
be sure the last frame we pushed is being served from the panel's
internal fb before shutting down the soc blocks (vop/analogix).
This patch changes the behavior such that we only wait for the
panel to complete the PSR transition when we're entering PSR, and
to skip verification when we're exiting.
With the subject fix:
Reviewed-by: Archit Taneja
Thanks,
Archit
Cc: Stéphane Marchesin
Cc: Sonny Rao
Signed-off-by: zain wang
Signed-off-by: Sean Paul
Signed-off-by: Thierry Escande
Signed-off-by: Enric Balletbo i Serra
Tested-by: Marek Szyprowski
---
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 4 ++--
drivers/gpu/drm/bridge/analogix/analogix_dp_core.h | 2 +-
drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 5 -
3 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 806c3878b3d6..5a2e35dc41e3 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -125,7 +125,7 @@ int analogix_dp_enable_psr(struct analogix_dp_device *dp)
psr_vsc.DB0 = 0;
psr_vsc.DB1 = EDP_VSC_PSR_STATE_ACTIVE | EDP_VSC_PSR_CRC_VALUES_VALID;
- return analogix_dp_send_psr_spd(dp, &psr_vsc);
+ return analogix_dp_send_psr_spd(dp, &psr_vsc, true);
}
EXPORT_SYMBOL_GPL(analogix_dp_enable_psr);
@@ -151,7 +151,7 @@ int analogix_dp_disable_psr(struct analogix_dp_device *dp)
if (ret != 1)
dev_err(dp->dev, "Failed to set DP Power0 %d\n", ret);
- return analogix_dp_send_psr_spd(dp, &psr_vsc);
+ return analogix_dp_send_psr_spd(dp, &psr_vsc, false);
}
EXPORT_SYMBOL_GPL(analogix_dp_disable_psr);
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
index 920607d7eb3e..6a96ef7e6934 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
@@ -253,7 +253,7 @@ void analogix_dp_enable_scrambling(struct
analogix_dp_device *dp);
void analogix_dp_disable_scrambling(struct analogix_dp_device *dp);
void analogix_dp_enable_psr_crc(struct analogix_dp_device *dp);
int analogix_dp_send_psr_spd(struct analogix_dp_device *dp,
-struct edp_vsc_psr *vsc);
+struct edp_vsc_psr *vsc, bool blocking);
ssize_t analogix_dp_transfer(struct analogix_dp_device *dp,
struct drm_dp_aux_msg *msg);
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
index 005a3f7005d2..9df2f3ef000c 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
@@ -1007,7 +1007,7 @@ static ssize_t analogix_dp_get_psr_status(struct
analogix_dp_device *dp)
}
int analogix_dp_send_psr_spd(struct analogix_dp_device *dp,
-struct edp_vsc_psr *vsc)
+struct edp_vsc_psr *vsc, bool blocking)
{
unsigned int val;
int ret;
@@ -1053,6 +1053,9 @@ int analogix_dp_send_psr_spd(struct analogix_dp_device
*dp,
val |= IF_EN;
writel(val, dp->reg_base + ANALOGIX_DP_PKT_SEND_CTL);
+ if (!blocking)
+ return 0;
+
ret = readx_poll_timeout(analogix_dp_get_psr_status, dp, psr_status,
psr_status >= 0 &&
((vsc->DB1 && psr_status == DP_PSR_SINK_ACTIVE_RFB) ||
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 05/36] drm/bridge: analogix_dp: add fast link train for eDP
On Saturday 10 March 2018 03:52 AM, Enric Balletbo i Serra wrote:
From: zain wang
We would meet a short black screen when exit PSR with the full link
training, In this case, we should use fast link train instead of full
link training.
Signed-off-by: zain wang
Signed-off-by: Sean Paul
Signed-off-by: Thierry Escande
Signed-off-by: Enric Balletbo i Serra
Tested-by: Marek Szyprowski
---
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 142 -
drivers/gpu/drm/bridge/analogix/analogix_dp_core.h | 3 +
2 files changed, 114 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index ee00d3d920e0..806c3878b3d6 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -10,17 +10,18 @@
* option) any later version.
*/
-#include
-#include
-#include
#include
-#include
+#include
+#include
+#include
#include
+#include
+#include
+#include
#include
#include
-#include
-#include
#include
+#include
This re-ordering doesn't seem like it should be a part of this patch,
you can let it stay if it happens to cause conflicts with future
patches. Other than that:
Reviewed-by: Archit Taneja
Thanks,
Archit
#include
#include
@@ -35,6 +36,8 @@
#define to_dp(nm) container_of(nm, struct analogix_dp_device, nm)
+static const bool verify_fast_training;
+
struct bridge_init {
struct i2c_client *client;
struct device_node *node;
@@ -528,7 +531,7 @@ static int analogix_dp_process_equalizer_training(struct
analogix_dp_device *dp)
{
int lane, lane_count, retval;
u32 reg;
- u8 link_align, link_status[2], adjust_request[2];
+ u8 link_align, link_status[2], adjust_request[2], spread;
usleep_range(400, 401);
@@ -571,6 +574,20 @@ static int analogix_dp_process_equalizer_training(struct analogix_dp_device *dp)
dev_dbg(dp->dev, "final lane count = %.2x\n",
dp->link_train.lane_count);
+ retval = drm_dp_dpcd_readb(&dp->aux, DP_MAX_DOWNSPREAD,
+ &spread);
+ if (retval != 1) {
+ dev_err(dp->dev, "failed to read downspread %d\n",
+ retval);
+ dp->fast_train_support = false;
+ } else {
+ dp->fast_train_support =
+ (spread & DP_NO_AUX_HANDSHAKE_LINK_TRAINING) ?
+ true : false;
+ }
+ dev_dbg(dp->dev, "fast link training %s\n",
+ dp->fast_train_support ? "supported" : "unsupported");
+
/* set enhanced mode if available */
analogix_dp_set_enhanced_mode(dp);
dp->link_train.lt_state = FINISHED;
@@ -627,10 +644,12 @@ static void analogix_dp_get_max_rx_lane_count(struct
analogix_dp_device *dp,
*lane_count = DPCD_MAX_LANE_COUNT(data);
}
-static void analogix_dp_init_training(struct analogix_dp_device *dp,
- enum link_lane_count_type max_lane,
- int max_rate)
+static int analogix_dp_full_link_train(struct analogix_dp_device *dp,
+ u32 max_lanes, u32 max_rate)
{
+ int retval = 0;
+ bool training_finished = false;
+
/*
* MACRO_RST must be applied after the PLL_LOCK to avoid
* the DP inter pair skew issue for at least 10 us
@@ -656,18 +675,13 @@ static void analogix_dp_init_training(struct
analogix_dp_device *dp,
}
/* Setup TX lane count & rate */
- if (dp->link_train.lane_count > max_lane)
- dp->link_train.lane_count = max_lane;
+ if (dp->link_train.lane_count > max_lanes)
+ dp->link_train.lane_count = max_lanes;
if (dp->link_train.link_rate > max_rate)
dp->link_train.link_rate = max_rate;
/* All DP analog module power up */
analogix_dp_set_analog_power_down(dp, POWER_ALL, 0);
-}
-
-static int analogix_dp_sw_link_training(struct analogix_dp_device *dp)
-{
- int retval = 0, training_finished = 0;
dp->link_train.lt_state = START;
@@ -702,22 +716,88 @@ static int analogix_dp_sw_link_training(struct analogix_dp_device *dp)
return retval;
}
-static int analogix_dp_set_link_train(struct analogix_dp_device *dp,
- u32 count, u32 bwtype)
+static int analogix_dp_fast_link_train(struct analogix_dp_device *dp)
{
- int i;
- int retval;
+ int i, ret;
+ u8 link_align, link_status[2];
+ enum pll_status status;
- for (i = 0; i < DP_TIMEOUT_LOOP_COUNT; i++) {
- analogix_dp_init_training(dp, count, bwtype);
- retval = ana
[DPU PATCH 1/2] dt-bindings: msm/disp: Remove hw block offset DT entries for SDM845
Remove DT entries of hw block offsets and other target specific catalog information for SDM845. Signed-off-by: Sravanthi Kollukuduru --- .../devicetree/bindings/display/msm/dpu.txt| 530 - 1 file changed, 530 deletions(-) diff --git a/Documentation/devicetree/bindings/display/msm/dpu.txt b/Documentation/devicetree/bindings/display/msm/dpu.txt index 136f0d3..90cd3e0 100644 --- a/Documentation/devicetree/bindings/display/msm/dpu.txt +++ b/Documentation/devicetree/bindings/display/msm/dpu.txt @@ -19,61 +19,6 @@ Required properties - interrupt-controller: Mark the device node as an interrupt controller. - #interrupt-cells: Should be one. The first cell is interrupt number. - iommus: Specifies the SID's used by this context bank. -- qcom,dpu-sspp-type: Array of strings for DPU source surface pipes type information. - A source pipe can be "vig", "rgb", "dma" or "cursor" type. - Number of xin ids defined should match the number of offsets - defined in property: qcom,dpu-sspp-off. -- qcom,dpu-sspp-off: Array of offset for DPU source surface pipes. The offsets - are calculated from register "mdp_phys" defined in - reg property + "dpu-off". The number of offsets defined here should - reflect the amount of pipes that can be active in DPU for - this configuration. -- qcom,dpu-sspp-xin-id:Array of VBIF clients ids (xins) corresponding - to the respective source pipes. Number of xin ids - defined should match the number of offsets - defined in property: qcom,dpu-sspp-off. -- qcom,dpu-ctl-off:Array of offset addresses for the available ctl - hw blocks within DPU, these offsets are - calculated from register "mdp_phys" defined in - reg property. The number of ctl offsets defined - here should reflect the number of control paths - that can be configured concurrently on DPU for - this configuration. -- qcom,dpu-wb-off: Array of offset addresses for the programmable - writeback blocks within DPU. -- qcom,dpu-wb-xin-id: Array of VBIF clients ids (xins) corresponding - to the respective writeback. Number of xin ids - defined should match the number of offsets - defined in property: qcom,dpu-wb-off. -- qcom,dpu-mixer-off: Array of offset addresses for the available - mixer blocks that can drive data to panel - interfaces. These offsets are be calculated from - register "mdp_phys" defined in reg property. - The number of offsets defined should reflect the - amount of mixers that can drive data to a panel - interface. -- qcom,dpu-dspp-top-off: Offset address for the dspp top block. - The offset is calculated from register "mdp_phys" - defined in reg property. -- qcom,dpu-dspp-off: Array of offset addresses for the available dspp - blocks. These offsets are calculated from - register "mdp_phys" defined in reg property. -- qcom,dpu-pp-off: Array of offset addresses for the available - pingpong blocks. These offsets are calculated - from register "mdp_phys" defined in reg property. -- qcom,dpu-pp-slave: Array of flags indicating whether each ping pong - block may be configured as a pp slave. -- qcom,dpu-intf-off: Array of offset addresses for the available DPU - interface blocks that can drive data to a - panel controller. The offsets are calculated - from "mdp_phys" defined in reg property. The number - of offsets defined should reflect the number of - programmable interface blocks available in hardware. -- qcom,dpu-mixer-blend-op-off Array of offset addresses for the available - blending stages. The offsets are relative to - qcom,dpu-mixer-off. -- qcom,dpu-mixer-pair-mask Array of mixer numbers that can be paired with - mixer number corresp
[DPU PATCH 0/2] Add hardware catalog information in driver source for SDM845
This patch series aims at adding the target specific hardware catalog information in driver source. As a result, the current logic of dt based parsing is removed. The DT clean up patch corresponding to this driver change will be posted separately. Sravanthi Kollukuduru (2): dt-bindings: msm/disp: Remove hw block offset DT entries for SDM845 drm/msm: Add hardware catalog file for SDM845 .../devicetree/bindings/display/msm/dpu.txt| 530 drivers/gpu/drm/msm/Makefile |1 + drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 3071 +--- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 17 +- .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog_sdm845.c | 744 + drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c|2 +- 6 files changed, 767 insertions(+), 3598 deletions(-) create mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog_sdm845.c -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH libdrm] tests/exynos: remove dead condition
There is already condition checking input values between 2 and 4096
so condition checking 0 is always false. Remove the dead condition.
Signed-off-by: Seung-Woo Kim
---
tests/exynos/exynos_fimg2d_perf.c |7 ---
1 files changed, 0 insertions(+), 7 deletions(-)
diff --git a/tests/exynos/exynos_fimg2d_perf.c
b/tests/exynos/exynos_fimg2d_perf.c
index a2d5c19..97691a7 100644
--- a/tests/exynos/exynos_fimg2d_perf.c
+++ b/tests/exynos/exynos_fimg2d_perf.c
@@ -274,13 +274,6 @@ int main(int argc, char **argv)
goto out;
}
- if (bufw == 0 || bufh == 0) {
- fprintf(stderr, "error: buffer width/height should be
non-zero.\n");
- ret = -1;
-
- goto out;
- }
-
fd = drmOpen("exynos", NULL);
if (fd < 0) {
fprintf(stderr, "error: failed to open drm\n");
--
1.7.4.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 03/36] drm/bridge: analogix_dp: Don't change psr while bridge is disabled
On Saturday 10 March 2018 03:52 AM, Enric Balletbo i Serra wrote:
From: zain wang
There is a race between AUX CH bring-up and enabling bridge which will
cause link training to fail. To avoid hitting it, don't change psr state
while enabling the bridge.
Reviewed-by: Archit Taneja
Cc: Tomeu Vizoso
Cc: Sean Paul
Signed-off-by: zain wang
Signed-off-by: Caesar Wang
[seanpaul fixed up the commit message a bit and renamed *_supported to
*_enabled]
Signed-off-by: Sean Paul
Signed-off-by: Thierry Escande
Signed-off-by: Enric Balletbo i Serra
Tested-by: Marek Szyprowski
---
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 15 ---
drivers/gpu/drm/bridge/analogix/analogix_dp_core.h | 2 +-
drivers/gpu/drm/rockchip/analogix_dp-rockchip.c| 2 +-
include/drm/bridge/analogix_dp.h | 2 +-
4 files changed, 11 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index e738aa6de1af..ee00d3d920e0 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -98,18 +98,18 @@ static int analogix_dp_detect_hpd(struct analogix_dp_device
*dp)
return 0;
}
-int analogix_dp_psr_supported(struct analogix_dp_device *dp)
+int analogix_dp_psr_enabled(struct analogix_dp_device *dp)
{
- return dp->psr_support;
+ return dp->psr_enable;
}
-EXPORT_SYMBOL_GPL(analogix_dp_psr_supported);
+EXPORT_SYMBOL_GPL(analogix_dp_psr_enabled);
int analogix_dp_enable_psr(struct analogix_dp_device *dp)
{
struct edp_vsc_psr psr_vsc;
- if (!dp->psr_support)
+ if (!dp->psr_enable)
return 0;
/* Prepare VSC packet as per EDP 1.4 spec, Table 6.9 */
@@ -131,7 +131,7 @@ int analogix_dp_disable_psr(struct analogix_dp_device *dp)
struct edp_vsc_psr psr_vsc;
int ret;
- if (!dp->psr_support)
+ if (!dp->psr_enable)
return 0;
/* Prepare VSC packet as per EDP 1.4 spec, Table 6.9 */
@@ -871,8 +871,8 @@ static void analogix_dp_commit(struct analogix_dp_device
*dp)
/* Enable video */
analogix_dp_start_video(dp);
- dp->psr_support = analogix_dp_detect_sink_psr(dp);
- if (dp->psr_support)
+ dp->psr_enable = analogix_dp_detect_sink_psr(dp);
+ if (dp->psr_enable)
analogix_dp_enable_sink_psr(dp);
}
@@ -1117,6 +1117,7 @@ static void analogix_dp_bridge_disable(struct drm_bridge *bridge)
if (ret)
DRM_ERROR("failed to setup the panel ret = %d\n", ret);
+ dp->psr_enable = false;
dp->dpms_mode = DRM_MODE_DPMS_OFF;
}
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
index b039b28d8fcc..e135a42cb19e 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
@@ -170,7 +170,7 @@ struct analogix_dp_device {
int dpms_mode;
int hpd_gpio;
boolforce_hpd;
- boolpsr_support;
+ boolpsr_enable;
struct mutex panel_lock;
boolpanel_is_modeset;
diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index 36334839a3f8..3e8bf79bea58 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -82,7 +82,7 @@ static void analogix_dp_psr_set(struct drm_encoder *encoder,
bool enabled)
struct rockchip_dp_device *dp = to_dp(encoder);
int ret;
- if (!analogix_dp_psr_supported(dp->adp))
+ if (!analogix_dp_psr_enabled(dp->adp))
return;
DRM_DEV_DEBUG(dp->dev, "%s PSR...\n", enabled ? "Entry" : "Exit");
diff --git a/include/drm/bridge/analogix_dp.h b/include/drm/bridge/analogix_dp.h
index 711fff9b6803..e9a1116d2f8e 100644
--- a/include/drm/bridge/analogix_dp.h
+++ b/include/drm/bridge/analogix_dp.h
@@ -41,7 +41,7 @@ struct analogix_dp_plat_data {
struct drm_connector *);
};
-int analogix_dp_psr_supported(struct analogix_dp_device *dp);
+int analogix_dp_psr_enabled(struct analogix_dp_device *dp);
int analogix_dp_enable_psr(struct analogix_dp_device *dp);
int analogix_dp_disable_psr(struct analogix_dp_device *dp);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 01/36] drm/bridge: analogix_dp: detect Sink PSR state after configuring the PSR
On Saturday 10 March 2018 03:52 AM, Enric Balletbo i Serra wrote:
From: Yakir Yang
Make sure the request PSR state takes effect in analogix_dp_send_psr_spd()
function, or print the sink PSR error state if we failed to apply the
requested PSR setting.
Reviewed-by: Archit Taneja
Cc: 征增 王
Cc: Stéphane Marchesin
Signed-off-by: Yakir Yang
[seanpaul changed timeout loop to a readx poll]
Signed-off-by: Sean Paul
Signed-off-by: Thierry Escande
Signed-off-by: Enric Balletbo i Serra
Tested-by: Marek Szyprowski
---
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 6 ++--
drivers/gpu/drm/bridge/analogix/analogix_dp_core.h | 6 ++--
drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 35 +++---
3 files changed, 37 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index a693ab3078f0..e738aa6de1af 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -122,8 +122,7 @@ int analogix_dp_enable_psr(struct analogix_dp_device *dp)
psr_vsc.DB0 = 0;
psr_vsc.DB1 = EDP_VSC_PSR_STATE_ACTIVE | EDP_VSC_PSR_CRC_VALUES_VALID;
- analogix_dp_send_psr_spd(dp, &psr_vsc);
- return 0;
+ return analogix_dp_send_psr_spd(dp, &psr_vsc);
}
EXPORT_SYMBOL_GPL(analogix_dp_enable_psr);
@@ -149,8 +148,7 @@ int analogix_dp_disable_psr(struct analogix_dp_device *dp)
if (ret != 1)
dev_err(dp->dev, "Failed to set DP Power0 %d\n", ret);
- analogix_dp_send_psr_spd(dp, &psr_vsc);
- return 0;
+ return analogix_dp_send_psr_spd(dp, &psr_vsc);
}
EXPORT_SYMBOL_GPL(analogix_dp_disable_psr);
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
index 5c6a28806129..b039b28d8fcc 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
@@ -20,6 +20,8 @@
#define MAX_CR_LOOP 5
#define MAX_EQ_LOOP 5
+#define DP_TIMEOUT_PSR_LOOP_MS 300
+
/* DP_MAX_LANE_COUNT */
#define DPCD_ENHANCED_FRAME_CAP(x)(((x) >> 7) & 0x1)
#define DPCD_MAX_LANE_COUNT(x)((x) & 0x1f)
@@ -247,8 +249,8 @@ void analogix_dp_config_video_slave_mode(struct
analogix_dp_device *dp);
void analogix_dp_enable_scrambling(struct analogix_dp_device *dp);
void analogix_dp_disable_scrambling(struct analogix_dp_device *dp);
void analogix_dp_enable_psr_crc(struct analogix_dp_device *dp);
-void analogix_dp_send_psr_spd(struct analogix_dp_device *dp,
- struct edp_vsc_psr *vsc);
+int analogix_dp_send_psr_spd(struct analogix_dp_device *dp,
+struct edp_vsc_psr *vsc);
ssize_t analogix_dp_transfer(struct analogix_dp_device *dp,
struct drm_dp_aux_msg *msg);
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
index 303083ad28e3..005a3f7005d2 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
@@ -10,10 +10,11 @@
* option) any later version.
*/
-#include
-#include
#include
+#include
#include
+#include
+#include
#include
@@ -992,10 +993,25 @@ void analogix_dp_enable_psr_crc(struct analogix_dp_device *dp)
writel(PSR_VID_CRC_ENABLE, dp->reg_base + ANALOGIX_DP_CRC_CON);
}
-void analogix_dp_send_psr_spd(struct analogix_dp_device *dp,
- struct edp_vsc_psr *vsc)
+static ssize_t analogix_dp_get_psr_status(struct analogix_dp_device *dp)
+{
+ ssize_t val;
+ u8 status;
+
+ val = drm_dp_dpcd_readb(&dp->aux, DP_PSR_STATUS, &status);
+ if (val < 0) {
+ dev_err(dp->dev, "PSR_STATUS read failed ret=%zd", val);
+ return val;
+ }
+ return status;
+}
+
+int analogix_dp_send_psr_spd(struct analogix_dp_device *dp,
+struct edp_vsc_psr *vsc)
{
unsigned int val;
+ int ret;
+ ssize_t psr_status;
/* don't send info frame */
val = readl(dp->reg_base + ANALOGIX_DP_PKT_SEND_CTL);
@@ -1036,6 +1052,17 @@ void analogix_dp_send_psr_spd(struct analogix_dp_device
*dp,
val = readl(dp->reg_base + ANALOGIX_DP_PKT_SEND_CTL);
val |= IF_EN;
writel(val, dp->reg_base + ANALOGIX_DP_PKT_SEND_CTL);
+
+ ret = readx_poll_timeout(analogix_dp_get_psr_status, dp, psr_status,
+ psr_status >= 0 &&
+ ((vsc->DB1 && psr_status == DP_PSR_SINK_ACTIVE_RFB) ||
+ (!vsc->DB1 && psr_status == DP_PSR_SINK_INACTIVE)), 1500,
+ DP_TIMEOUT_PSR_LOOP_MS * 1000);
+ if (ret) {
+ dev_warn(dp->dev, "Failed to apply PSR %d\n", ret);
+ return ret;
+ }
+ return 0;
}
ssi
[Bug 102905] [R600] Miscompilation of TGSI to VLIW causes artifacts in Gallium Nine with Crysis2 bump mapping
https://bugs.freedesktop.org/show_bug.cgi?id=102905 Roland Scheidegger changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #5 from Roland Scheidegger --- Fixed by 274f8bf05ef526d65f01614313dda65bc7ec7a87. Thanks for the analysis! (the code wasn't really all that difficult after that...) -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 104037] [drm] GPU HANG: ecode 9:0:0x87f9bffb, in Xorg [1688], reason: Hang on rcs0, action: reset
https://bugs.freedesktop.org/show_bug.cgi?id=104037 --- Comment #1 from sh...@mcewan.id.au --- Created attachment 138087 --> https://bugs.freedesktop.org/attachment.cgi?id=138087&action=edit Content of /sys/class/drm/card0/error I'm also getting this exact error. I was running XScreensaver at the time. I think the `rubikblocks` GL hack was running. Ubuntu 17.10 4.13.0-36-generic OpenGL version string: 3.0 Mesa 17.2.8 Lenovo ThinkPad X1 Carbon 4th Gen Intel(R) Core(TM) i5-6300U CPU @ 2.40GHz eDP-1 connected primary 2560x1440+0+1440 HDMI-2 connected 2560x1440+0+0 filename: /lib/modules/4.13.0-36-generic/kernel/drivers/gpu/drm/i915/i915.ko license:GPL and additional rights description:Intel Graphics author: Intel Corporation author: Tungsten Graphics, Inc. firmware: i915/bxt_dmc_ver1_07.bin firmware: i915/skl_dmc_ver1_26.bin firmware: i915/kbl_dmc_ver1_01.bin firmware: i915/skl_guc_ver6_1.bin firmware: i915/kbl_huc_ver02_00_1810.bin firmware: i915/bxt_huc_ver01_07_1398.bin firmware: i915/skl_huc_ver01_07_1398.bin srcversion: F27B28CF28ECAE28997AF44 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 100726] [REGRESSION][BISECTED] Severe flickering with an R9 290
https://bugs.freedesktop.org/show_bug.cgi?id=100726 --- Comment #9 from hiwatari.se...@gmail.com --- My last try of bisecting the error. I'm pretty sure I've got the correct commit this time. I first ran 4 Weeks on the 4.9-rc1 without the error ever appearing, upgraded to one or two release candidates higher, rebooted and instantly had the error. I then did the bisecting in this window, waiting 3-4 Weeks for the error to appear per commit, before flagging the kernel as ok. Git then tells me, that 5f7f8f6edbf860abf18149a64be036d4be5e2993 is the first bad commit. I will attach the new bisect log. I don't know if the error might already have been fixed, since I've been months on this ancient version. But I will try that in the following weeks. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 100726] [REGRESSION][BISECTED] Severe flickering with an R9 290
https://bugs.freedesktop.org/show_bug.cgi?id=100726 --- Comment #10 from hiwatari.se...@gmail.com --- Created attachment 138086 --> https://bugs.freedesktop.org/attachment.cgi?id=138086&action=edit Bisect Log 3 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [GIT PULL] omapdrm changes for v4.17
On 7 March 2018 at 18:27, Tomi Valkeinen wrote: > Hi Dave, > > Please pull omapdrm changes for v4.17. Hi Tomi, Sorry for delay, pulled this it broken my ARM build /home/airlied/devel/kernel/drm-next/drivers/gpu/drm/omapdrm/dss/dss.c: In function ‘dss_probe’: /home/airlied/devel/kernel/drm-next/drivers/gpu/drm/omapdrm/dss/dss.c:1474:10: error: ‘dss_debug_dump_clocks’ undeclared (first use in this function); did you mean ‘dispc_dump_clocks’? dss_debug_dump_clocks, dss); ^ dispc_dump_clocks /home/airlied/devel/kernel/drm-next/drivers/gpu/drm/omapdrm/dss/dss.c:1474:10: note: each undeclared identifier is reported only once for each function it appears in make[6]: *** [/home/airlied/devel/kernel/drm-next/scripts/Makefile.build:316: drivers/gpu/drm/omapdrm/dss/dss.o] Error 1 Looks like a per-config, please push a fix on top and resend the pull req. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH] drm/xen-front: xen_drm_front_platform_info can be static
Fixes: db81084f9084 ("drm/xen-front: Add support for Xen PV display frontend")
Signed-off-by: Fengguang Wu
---
xen_drm_front.c |2 +-
xen_drm_front_drv.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/xen/xen_drm_front.c
b/drivers/gpu/drm/xen/xen_drm_front.c
index dbabdf9..f421d23 100644
--- a/drivers/gpu/drm/xen/xen_drm_front.c
+++ b/drivers/gpu/drm/xen/xen_drm_front.c
@@ -417,7 +417,7 @@ static int xen_drm_drv_remove(struct platform_device *pdev)
return xen_drm_front_drv_remove(pdev);
}
-struct platform_device_info xen_drm_front_platform_info = {
+static struct platform_device_info xen_drm_front_platform_info = {
.name = XENDISPL_DRIVER_NAME,
.id = 0,
.num_res = 0,
diff --git a/drivers/gpu/drm/xen/xen_drm_front_drv.c
b/drivers/gpu/drm/xen/xen_drm_front_drv.c
index 3edefa2..04ee389 100644
--- a/drivers/gpu/drm/xen/xen_drm_front_drv.c
+++ b/drivers/gpu/drm/xen/xen_drm_front_drv.c
@@ -122,7 +122,7 @@ static const struct vm_operations_struct xen_drm_vm_ops = {
.close = drm_gem_vm_close,
};
-struct drm_driver xen_drm_driver = {
+static struct drm_driver xen_drm_driver = {
.driver_features = DRIVER_GEM | DRIVER_MODESET |
DRIVER_PRIME | DRIVER_ATOMIC,
.lastclose = lastclose,
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RESEND v2 1/2] drm/xen-front: Add support for Xen PV display frontend
Hi Oleksandr, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on linus/master] [also build test WARNING on v4.16-rc5 next-20180313] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Oleksandr-Andrushchenko/drm-xen-front-Add-support-for-Xen-PV-display-frontend/20180314-014856 reproduce: # apt-get install sparse make ARCH=x86_64 allmodconfig make C=1 CF=-D__CHECK_ENDIAN__ sparse warnings: (new ones prefixed by >>) >> drivers/gpu/drm/xen/xen_drm_front.c:420:29: sparse: symbol >> 'xen_drm_front_platform_info' was not declared. Should it be static? -- >> drivers/gpu/drm/xen/xen_drm_front_drv.c:125:19: sparse: symbol >> 'xen_drm_driver' was not declared. Should it be static? Please review and possibly fold the followup patch. --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [DPU PATCH 02/11] drm/msm: Don't duplicate modeset_enables atomic helper
On 2018-03-12 13:21, Sean Paul wrote:
On Thu, Mar 08, 2018 at 04:56:01PM -0800, Jeykumar Sankaran wrote:
On 2018-02-28 11:18, Sean Paul wrote:
> Instead, shuffle things around so we kickoff crtc after enabling
encoder
> during modesets. Also moves the vblank wait to after the frame.
>
> Change-Id: I16c7b7f9390d04f6050aa20e17a5335fbf49eba3
> Signed-off-by: Sean Paul
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c| 9 ++
> drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 5 +-
> drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 31 -
> drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 2 +
> drivers/gpu/drm/msm/msm_atomic.c| 132
+---
> 5 files changed, 48 insertions(+), 131 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> index a3ab6ed2bf1d..94fab2dcca5b 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> @@ -3525,6 +3525,12 @@ static void dpu_crtc_enable(struct drm_crtc
> *crtc,
>DPU_EVT32_VERBOSE(DRMID(crtc));
>dpu_crtc = to_dpu_crtc(crtc);
>
> + if (msm_is_mode_seamless(&crtc->state->adjusted_mode) ||
> + msm_is_mode_seamless_vrr(&crtc->state->adjusted_mode)) {
> + DPU_DEBUG("Skipping crtc enable, seamless mode\n");
> + return;
> + }
> +
>pm_runtime_get_sync(crtc->dev->dev);
>
>drm_for_each_encoder(encoder, crtc->dev) {
> @@ -3572,6 +3578,9 @@ static void dpu_crtc_enable(struct drm_crtc
*crtc,
>DPU_POWER_EVENT_POST_ENABLE | DPU_POWER_EVENT_POST_DISABLE
> |
>DPU_POWER_EVENT_PRE_DISABLE,
>dpu_crtc_handle_power_event, crtc, dpu_crtc->name);
> +
> + if (msm_needs_vblank_pre_modeset(&crtc->state->adjusted_mode))
> + drm_crtc_wait_one_vblank(crtc);
> }
>
> struct plane_state {
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> index 28ceb589ee40..4d1e3652dbf4 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> @@ -3693,8 +3693,11 @@ static void
dpu_encoder_frame_done_timeout(struct
> timer_list *t)
> static const struct drm_encoder_helper_funcs dpu_encoder_helper_funcs
=
> {
>.mode_set = dpu_encoder_virt_mode_set,
>.disable = dpu_encoder_virt_disable,
> - .enable = dpu_encoder_virt_enable,
> + .enable = dpu_kms_encoder_enable,
>.atomic_check = dpu_encoder_virt_atomic_check,
> +
> + /* This is called by dpu_kms_encoder_enable */
> + .commit = dpu_encoder_virt_enable,
> };
>
> static const struct drm_encoder_funcs dpu_encoder_funcs = {
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> index 81fd3a429e9f..3d83037e8305 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> @@ -425,14 +425,37 @@ static void dpu_kms_prepare_commit(struct
msm_kms
> *kms,
>dpu_encoder_prepare_commit(encoder);
> }
>
> -static void dpu_kms_commit(struct msm_kms *kms,
> - struct drm_atomic_state *old_state)
> +/*
> + * Override the encoder enable since we need to setup the inline
> rotator
> and do
> + * some crtc magic before enabling any bridge that might be present.
> + */
> +void dpu_kms_encoder_enable(struct drm_encoder *encoder)
> +{
> + const struct drm_encoder_helper_funcs *funcs =
> encoder->helper_private;
> + struct drm_crtc *crtc = encoder->crtc;
> +
> + /* Forward this enable call to the commit hook */
> + if (funcs && funcs->commit)
> + funcs->commit(encoder);
The purpose of this function is not clear. Where are we setting up the
inline rotator?
Why do we need a kickoff here?
The reason the code is shuffled is to avoid duplicating the entire
atomic
helper
function. By moving calls into the ->enable hooks, we can avoid having
to
hand
roll the helpers.
The kickoff is preserved from the helper copy when you call
kms->funcs->commit
in between the encoder enable and bridge enable. If this can be
removed,
that'd
be even better. I was simply trying to preserve the call order of
everything.
Sean
I am with you on cleaning up the atomic helper copy. But using
enc->commit helper
to call into encoder_enable doesn't look valid to me.
Also, I verified removing the kms->funcs->commit call between encoder
enable and
bridge enable. It works fine with your newly placed kms->funcs->commit
after
drm_atomic_helper_commit_modeset_enables. So can you revisit this
function?
Jeykumar S
> +
> + if (crtc && crtc->state->active) {
> + DPU_EVT32(DRMID(crtc));
> + dpu_crtc_commit_kickoff(crtc);
> + }
> +}
> +
> +static void dpu_kms_commit(struct msm_kms *kms, struct
drm_atomic_state
> *state)
> {
>struct drm_crtc *crtc;
> - struct drm_crtc_state *old_crtc_state;
> + struct drm_crtc_state *crtc_state;
> + struct dpu_crtc_state *cstate;
>int i;
>
> - for_each_old_c
[PATCH v5] drm_hwcomposer: Add platformhisi buffer importer for hikey and hikey960
This allows for importing buffers allocated from the
hikey and hikey960 gralloc implementations.
Cc: Marissa Wall
Cc: Sean Paul
Cc: Dmitry Shmidt
Cc: Robert Foss
Cc: Matt Szczesiak
Cc: Liviu Dudau
Cc: David Hanna
Cc: Rob Herring
Cc: Alexandru-Cosmin Gheorghe
Cc: Alistair Strachan
Acked-by: Robert Foss
Signed-off-by: John Stultz
---
v2:
* Make platformhisi and the generic importer exclusive in the
build
* Fixup vendor check
v3:
* Unify format conversions
* Subclass the platformdrmgeneric importer implementation to
reduce code duplication
* Rework to avoid board specific logic (tweak gralloc to be
consistent between the two)
v4:
* Minor cleanups as suggested by Alexandru-Cosmin Gheorghe
v5:
* Minor spelling fix in commit message noticed by Robert Foss
---
Android.mk | 13 +
platformdrmgeneric.h | 2 +-
platformhisi.cpp | 135 +++
platformhisi.h | 48 ++
4 files changed, 197 insertions(+), 1 deletion(-)
create mode 100644 platformhisi.cpp
create mode 100644 platformhisi.h
diff --git a/Android.mk b/Android.mk
index 8b11e37..1add286 100644
--- a/Android.mk
+++ b/Android.mk
@@ -75,7 +75,20 @@ LOCAL_CPPFLAGS += \
-DHWC2_USE_CPP11 \
-DHWC2_INCLUDE_STRINGIFICATION
+
+ifeq ($(TARGET_PRODUCT),hikey960)
+LOCAL_CPPFLAGS += -DUSE_HISI_IMPORTER
+LOCAL_SRC_FILES += platformhisi.cpp
+LOCAL_C_INCLUDES += device/linaro/hikey/gralloc960/
+else
+ifeq ($(TARGET_PRODUCT),hikey)
+LOCAL_CPPFLAGS += -DUSE_HISI_IMPORTER
+LOCAL_SRC_FILES += platformhisi.cpp
+LOCAL_C_INCLUDES += device/linaro/hikey/gralloc/
+else
LOCAL_CPPFLAGS += -DUSE_DRM_GENERIC_IMPORTER
+endif
+endif
LOCAL_MODULE := hwcomposer.drm
LOCAL_MODULE_TAGS := optional
diff --git a/platformdrmgeneric.h b/platformdrmgeneric.h
index 8376580..fbe059b 100644
--- a/platformdrmgeneric.h
+++ b/platformdrmgeneric.h
@@ -35,8 +35,8 @@ class DrmGenericImporter : public Importer {
int ImportBuffer(buffer_handle_t handle, hwc_drm_bo_t *bo) override;
int ReleaseBuffer(hwc_drm_bo_t *bo) override;
- private:
uint32_t ConvertHalFormatToDrm(uint32_t hal_format);
+ private:
DrmResources *drm_;
diff --git a/platformhisi.cpp b/platformhisi.cpp
new file mode 100644
index 000..16c5e6f
--- /dev/null
+++ b/platformhisi.cpp
@@ -0,0 +1,135 @@
+/*
+ * Copyright (C) 2015 The Android Open Source Project
+ *
+ * Licensed under the Apache License, Version 2.0 (the "License");
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+#define LOG_TAG "hwc-platform-hisi"
+
+#include "drmresources.h"
+#include "platform.h"
+#include "platformhisi.h"
+
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include "gralloc_priv.h"
+
+
+namespace android {
+
+Importer *Importer::CreateInstance(DrmResources *drm) {
+ HisiImporter *importer = new HisiImporter(drm);
+ if (!importer)
+return NULL;
+
+ int ret = importer->Init();
+ if (ret) {
+ALOGE("Failed to initialize the hisi importer %d", ret);
+delete importer;
+return NULL;
+ }
+ return importer;
+}
+
+HisiImporter::HisiImporter(DrmResources *drm) : DrmGenericImporter(drm),
drm_(drm) {
+}
+
+HisiImporter::~HisiImporter() {
+}
+
+int HisiImporter::Init() {
+ int ret = hw_get_module(GRALLOC_HARDWARE_MODULE_ID,
+ (const hw_module_t **)&gralloc_);
+ if (ret) {
+ALOGE("Failed to open gralloc module %d", ret);
+return ret;
+ }
+
+ if (strcasecmp(gralloc_->common.author, "ARM Ltd."))
+ALOGW("Using non-ARM gralloc module: %s/%s\n", gralloc_->common.name,
+ gralloc_->common.author);
+
+ return 0;
+}
+
+EGLImageKHR HisiImporter::ImportImage(EGLDisplay egl_display, buffer_handle_t
handle) {
+ private_handle_t const *hnd = reinterpret_cast < private_handle_t const
*>(handle);
+ if (!hnd)
+return NULL;
+
+ EGLint fmt = ConvertHalFormatToDrm(hnd->req_format);
+ if (fmt < 0)
+ return NULL;
+
+ EGLint attr[] = {
+EGL_WIDTH, hnd->width,
+EGL_HEIGHT, hnd->height,
+EGL_LINUX_DRM_FOURCC_EXT, fmt,
+EGL_DMA_BUF_PLANE0_FD_EXT, hnd->share_fd,
+EGL_DMA_BUF_PLANE0_OFFSET_EXT, 0,
+EGL_DMA_BUF_PLANE0_PITCH_EXT, hnd->byte_stride,
+EGL_NONE,
+ };
+ return eglCreateImageKHR(egl_display, EGL_NO_CONTEXT, EGL_LINUX_DMA_BUF_EXT,
NULL, attr);
+}
+
+int HisiImporter::ImportBuffer(buffer_handle_t handle, hwc_drm_bo_t *bo) {
+ private_handle_t const *hnd = reinterpret_cast < private_handle_t const
*>(handle);
+ if (!hnd)
+return -EINVAL;
+
+ ui
[Bug 105463] [r600g] 4210 piglit failures, 55 crashes, 14 warnings on ppc (PCIe, ppc64, mesa-18.0.0_rc4)
https://bugs.freedesktop.org/show_bug.cgi?id=105463 --- Comment #6 from erhar...@mailbox.org --- Created attachment 138085 --> https://bugs.freedesktop.org/attachment.cgi?id=138085&action=edit html summary from 'pigllit run all' with LLVM -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 1/5] drm/i915: Move DP modeset retry work into intel_dp
On Mon, 2018-03-12 at 23:01 +0200, Ville Syrjälä wrote:
> On Fri, Mar 09, 2018 at 04:32:27PM -0500, Lyude Paul wrote:
> > While having the modeset_retry_work in intel_connector makes sense with
> > SST, this paradigm doesn't make a whole ton of sense when it comes to
> > MST since we have to deal with multiple connectors. In most cases, it's
> > more useful to just use the intel_dp struct since it indicates whether
> > or not we're dealing with an MST device, along with being able to easily
> > trace the intel_dp struct back to it's respective connector (if there is
> > any). So, move the modeset_retry_work function out of the
> > intel_connector struct and into intel_dp.
> >
> > Signed-off-by: Lyude Paul
> > Reviewed-by: Manasi Navare
> > Cc: Manasi Navare
> > Cc: Ville Syrjälä
> >
> > V2:
> > - Remove accidental duplicate modeset_retry_work in intel_connector
> > V3:
> > - Also check against eDP in intel_hpd_poll_fini() - mdnavare
> > Signed-off-by: Lyude Paul
> > ---
> > drivers/gpu/drm/i915/intel_display.c | 25 +++-
> > -
> > drivers/gpu/drm/i915/intel_dp.c | 10 --
> > drivers/gpu/drm/i915/intel_dp_link_training.c | 2 +-
> > drivers/gpu/drm/i915/intel_drv.h | 6 +++---
> > 4 files changed, 31 insertions(+), 12 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index f424fff477f6..3b7fa430a84a 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -15394,16 +15394,37 @@ static void intel_hpd_poll_fini(struct drm_device
> > *dev)
> > {
> > struct intel_connector *connector;
> > struct drm_connector_list_iter conn_iter;
> > + struct work_struct *work;
> > + int conn_type;
> >
> > /* Kill all the work that may have been queued by hpd. */
> > drm_connector_list_iter_begin(dev, &conn_iter);
> > for_each_intel_connector_iter(connector, &conn_iter) {
> > - if (connector->modeset_retry_work.func)
> > - cancel_work_sync(&connector->modeset_retry_work);
> > if (connector->hdcp_shim) {
> > cancel_delayed_work_sync(&connector-
> > >hdcp_check_work);
> > cancel_work_sync(&connector->hdcp_prop_work);
> > }
> > +
> > + conn_type = connector->base.connector_type;
> > + if (conn_type != DRM_MODE_CONNECTOR_eDP &&
> > + conn_type != DRM_MODE_CONNECTOR_DisplayPort)
> > + continue;
> > +
> > + if (connector->mst_port) {
> > + work = &connector->mst_port->modeset_retry_work;
> > + } else {
> > + struct intel_encoder *intel_encoder =
> > + connector->encoder;
> > + struct intel_dp *intel_dp;
> > +
> > + if (!intel_encoder)
> > + continue;
> > +
> > + intel_dp = enc_to_intel_dp(&intel_encoder->base);
> > + work = &intel_dp->modeset_retry_work;
> > + }
> > +
> > + cancel_work_sync(work);
>
> Why are we even walking the connectors for this? Can't we just
> walk the encoders instead?
We could walk the encoders for this, but seeing as we're already walking the
connectors for the HDCP prop doesn't it make more sense to just stick our code
there? or is there a simpler solution for this I'm missing
>
> > }
> > drm_connector_list_iter_end(&conn_iter);
> > }
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index 4dd1b2287dd6..5abf0c95725a 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -6261,12 +6261,10 @@ static bool intel_edp_init_connector(struct intel_dp
> > *intel_dp,
> >
> > static void intel_dp_modeset_retry_work_fn(struct work_struct *work)
> > {
> > - struct intel_connector *intel_connector;
> > - struct drm_connector *connector;
> > + struct intel_dp *intel_dp = container_of(work, typeof(*intel_dp),
> > +modeset_retry_work);
> > + struct drm_connector *connector = &intel_dp->attached_connector-
> > >base;
> >
> > - intel_connector = container_of(work, typeof(*intel_connector),
> > - modeset_retry_work);
> > - connector = &intel_connector->base;
> > DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n", connector->base.id,
> > connector->name);
> >
> > @@ -6295,7 +6293,7 @@ intel_dp_init_connector(struct intel_digital_port
> > *intel_dig_port,
> > int type;
> >
> > /* Initialize the work for modeset in case of link train failure */
> > - INIT_WORK(&intel_connector->modeset_retry_work,
> > + INIT_WORK(&intel_dp->modeset_retry_work,
> > intel_dp_modeset_retry_work_fn);
> >
> > if (WARN(intel_dig_port->max_lanes < 1,
> > diff --git a/dr
Re: [PATCH v3 2/5] drm/i915: Only use one link bw config for MST topologies
On Mon, 2018-03-12 at 13:45 -0700, Manasi Navare wrote:
> On Fri, Mar 09, 2018 at 04:32:28PM -0500, Lyude Paul wrote:
> > When a DP MST link needs retraining, sometimes the hub will detect that
> > the current link bw config is impossible and will update it's RX caps in
> > the DPCD to reflect the new maximum link rate. Currently, we make the
> > assumption that the RX caps in the dpcd will never change like this.
> > This means if the sink changes it's RX caps after we've already set up
> > an MST link and we attempt to add or remove another sink from the
> > topology, we could put ourselves into an invalid state where we've tried
> > to configure different sinks on the same MST topology with different
> > link rates. We could also run into this situation if a sink reports a
> > higher link rate after suspend, usually from us having trained it with a
> > fallback bw configuration before suspending.
> >
> > So: "lock" the bw config by only using the max DP link rate/lane count
> > on the first modeset for an MST topology. For every modeset following,
> > we instead use the last configured link bw for this topology. We only
> > unlock the bw config when we've detected a new MST sink.
> >
>
> Just a nit here on commit message about where we unlock the link bw. So we
> also unlock it
> meaning set the mst_link_bw_locked to false when we read the dpcd again
> and obtain the fallback values since at that time the RX cap could have
> changed and so we do unlock the link_bw so that during retraining it reads
> the new max link rate and lane count during the mst compute config.
> Isnt that the case or am I missing something here?
I'm not sure I understand what you mean, are you talking about how we unlock the
link bw when retraining fails and we decide to fallback? If so, that's probably
something we should just mention in the patch that implements the actual
retraining as opposed to this patch.
>
> Manasi
>
> > Signed-off-by: Lyude Paul
> > Cc: Manasi Navare
> > Cc: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/intel_dp.c | 11 +--
> > drivers/gpu/drm/i915/intel_dp_mst.c | 22 +++---
> > drivers/gpu/drm/i915/intel_drv.h| 6 ++
> > 3 files changed, 30 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index 5abf0c95725a..5645a194de92 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -3871,18 +3871,25 @@ intel_dp_can_mst(struct intel_dp *intel_dp)
> > static void
> > intel_dp_configure_mst(struct intel_dp *intel_dp)
> > {
> > + bool was_mst;
> > +
> > if (!i915_modparams.enable_dp_mst)
> > return;
> >
> > if (!intel_dp->can_mst)
> > return;
> >
> > + was_mst = intel_dp->is_mst;
> > intel_dp->is_mst = intel_dp_can_mst(intel_dp);
> >
> > - if (intel_dp->is_mst)
> > + if (intel_dp->is_mst) {
> > DRM_DEBUG_KMS("Sink is MST capable\n");
> > - else
> > +
> > + if (!was_mst)
> > + intel_dp->mst_bw_locked = false;
> > + } else {
> > DRM_DEBUG_KMS("Sink is not MST capable\n");
> > + }
> >
> > drm_dp_mst_topology_mgr_set_mst(&intel_dp->mst_mgr,
> > intel_dp->is_mst);
> > diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c
> > b/drivers/gpu/drm/i915/intel_dp_mst.c
> > index c3de0918ee13..c0553456b18e 100644
> > --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> > +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> > @@ -42,7 +42,7 @@ static bool intel_dp_mst_compute_config(struct
> > intel_encoder *encoder,
> > to_intel_connector(conn_state->connector);
> > struct drm_atomic_state *state = pipe_config->base.state;
> > int bpp;
> > - int lane_count, slots;
> > + int lane_count, link_rate, slots;
> > const struct drm_display_mode *adjusted_mode = &pipe_config-
> > >base.adjusted_mode;
> > int mst_pbn;
> > bool reduce_m_n = drm_dp_has_quirk(&intel_dp->desc,
> > @@ -56,16 +56,22 @@ static bool intel_dp_mst_compute_config(struct
> > intel_encoder *encoder,
> > bpp);
> > }
> > /*
> > -* for MST we always configure max link bw - the spec doesn't
> > -* seem to suggest we should do otherwise.
> > +* for MST we always configure max link bw if we don't know better
> > -
> > +* the spec doesn't seem to suggest we should do otherwise. But,
> > +* ensure it always stays consistent with the rest of this hub's
> > +* state.
> > */
> > - lane_count = intel_dp_max_lane_count(intel_dp);
> > + if (intel_dp->mst_bw_locked) {
> > + lane_count = intel_dp->lane_count;
> > + link_rate = intel_dp->link_rate;
> > + } else {
> > + lane_count = intel_dp_max_lane_count(intel_dp);
> > + link_rate = intel_dp_max_link_rate(intel_dp);
> > + }
> >
> > pipe_config->lane_count = lane_count;
> > -
> > pipe_co
[Bug 105463] [r600g] 4210 piglit failures, 55 crashes, 14 warnings on ppc (PCIe, ppc64, mesa-18.0.0_rc4)
https://bugs.freedesktop.org/show_bug.cgi?id=105463 --- Comment #5 from erhar...@mailbox.org --- Created attachment 138084 --> https://bugs.freedesktop.org/attachment.cgi?id=138084&action=edit results from 'pigllit run all' with LLVM -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/panel: rm68200: add backlight dependency
On Tue, Mar 13, 2018 at 09:59:54PM +0100, Arnd Bergmann wrote:
> Like many other panel drivers, this one fails to build
> when backlight support is disabled:
>
> drivers/gpu/drm/panel/panel-raydium-rm68200.o: In function `rm68200_probe':
> panel-raydium-rm68200.c:(.text+0x14a): undefined reference to
> `devm_of_find_backlight'
>
> This adds the appropriate dependency.
>
> Fixes: 2b7ed18bed1a ("drm/panel: Add support for Raydium RM68200 panel
> driver")
> Signed-off-by: Arnd Bergmann
> ---
> drivers/gpu/drm/panel/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
This shouldn't be necessary. include/linux/backlight.h defines a stub if
the backlight class is not enabled.
What tree are you seeing this on?
Thierry
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 00/10] splash screen on the stm32f769 disco board
On Tue, Mar 13, 2018 at 04:23:10PM +0100, Daniel Vetter wrote: > On Tue, Mar 13, 2018 at 02:49:59PM +0100, yannick fertre wrote: > > Version 3: > > - Replace some pr_error, pr_warn or pr_info by dev_error, dev_warn & > > dev_info. > > - Refresh stm32f769-disco_defconfig with last modification done on > > v2018.3-rc4. > > - rework include files ordering. > > > > Version 2: > > - Replace debug log by pr_error, pr_warn or pr_info. > > - Rework bridge between ltdc & dsi panel > > - Rework backligh management (with or witout gpio) > > - Rework panel otm8009a > > - Add new panel raydium rm68200 > > > > Version 1: > > - Initial commit > > > > This serie contains all patchsets needed for displaying a splash screen > > on the stm32f769 disco board. > > A new config has been created configs/stm32f769-disco_defconfig. > > This is necessary due to the difference of panels between stm32f769-disco & > > stm32f746-disco boards. > > Shouldn't we patch the drivers/gpu/drm/stm driver instead of the > drivers/video one? fbdev is kinda a dead end and not for adding new hw > support ... This is confusing, but by the looks of it this is code for U-Boot display support and has nothing to do with the Linux kernel. I don't know why dri-devel was on Cc. Yannick, it's not customary to cross-post U-Boot display drivers to Linux mailing lists, unless there's some need to coordinate or discuss across the boundaries (for example if you were proposing a way to do seamless handover from U-Boot to kernel). If you do cross-post, perhaps make sure to mark these patches as targetting U-Boot to avoid confusion. Thierry signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 105463] [r600g] 4210 piglit failures, 55 crashes, 14 warnings on ppc (PCIe, ppc64, mesa-18.0.0_rc4)
https://bugs.freedesktop.org/show_bug.cgi?id=105463 --- Comment #4 from erhar...@mailbox.org --- Same setup but with mesa built with LLVM support: # ./piglit run -s all results/OpenGL_all_llvm Skipping GL_ARB_gpu_shader_fp64 tests [54211/54211] skip: 30608, pass: 20471, warn: 15, fail: 3044, crash: 73 Thank you for running Piglit! Results have been written to /root/build/piglit/results/OpenGL_all_llvm $ glxinfo | grep -i opengl OpenGL vendor string: X.Org OpenGL renderer string: AMD CAICOS (DRM 2.49.0 / 4.9.87-gentoo, LLVM 5.0.1) OpenGL core profile version string: 3.2 (Core Profile) Mesa 18.0.0-rc4 OpenGL core profile shading language version string: 1.50 OpenGL core profile context flags: (none) OpenGL core profile profile mask: core profile OpenGL core profile extensions: OpenGL version string: 3.0 Mesa 18.0.0-rc4 OpenGL shading language version string: 1.30 OpenGL context flags: (none) OpenGL extensions: OpenGL ES profile version string: OpenGL ES 3.1 Mesa 18.0.0-rc4 OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.10 OpenGL ES profile extensions: -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: Reduce object size of DRM_ERROR and DRM_DEBUG uses
drm_printk is used for both DRM_ERROR and DRM_DEBUG with unnecessary
arguments that can be removed by creating separate functins.
Create specific functions for these calls to reduce x86/64 defconfig
size by ~20k.
Modify the existing macros to use the specific calls.
new:
$ size -t drivers/gpu/drm/built-in.a | tail -1
1876562 44542 995 1922099 1d5433 (TOTALS)
old:
$ size -t drivers/gpu/drm/built-in.a | tail -1
1897565 44542 995 1943102 1da63e (TOTALS)
Miscellanea:
o intel_display requires a change to use the specific calls.
Signed-off-by: Joe Perches
---
drivers/gpu/drm/drm_print.c | 28 +---
drivers/gpu/drm/i915/intel_display.c | 15 ---
include/drm/drm_print.h | 27 ++-
3 files changed, 39 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/drm_print.c b/drivers/gpu/drm/drm_print.c
index 781518fd88e3..79abf6d5b4db 100644
--- a/drivers/gpu/drm/drm_print.c
+++ b/drivers/gpu/drm/drm_print.c
@@ -89,23 +89,37 @@ void drm_dev_printk(const struct device *dev, const char
*level,
}
EXPORT_SYMBOL(drm_dev_printk);
-void drm_printk(const char *level, unsigned int category,
- const char *format, ...)
+void drm_dbg(unsigned int category, const char *format, ...)
{
struct va_format vaf;
va_list args;
- if (category != DRM_UT_NONE && !(drm_debug & category))
+ if (!(drm_debug & category))
return;
va_start(args, format);
vaf.fmt = format;
vaf.va = &args;
- printk("%s" "[" DRM_NAME ":%ps]%s %pV",
- level, __builtin_return_address(0),
- strcmp(level, KERN_ERR) == 0 ? " *ERROR*" : "", &vaf);
+ printk(KERN_DEBUG "[" DRM_NAME ":%ps] %pV",
+ __builtin_return_address(0), &vaf);
+
+ va_end(args);
+}
+EXPORT_SYMBOL(drm_dbg);
+
+void drm_err(const char *format, ...)
+{
+ struct va_format vaf;
+ va_list args;
+
+ va_start(args, format);
+ vaf.fmt = format;
+ vaf.va = &args;
+
+ printk(KERN_ERR "[" DRM_NAME ":%ps] *ERROR* %pV",
+ __builtin_return_address(0), &vaf);
va_end(args);
}
-EXPORT_SYMBOL(drm_printk);
+EXPORT_SYMBOL(drm_err);
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 2933ad38094f..d8e522e3cd39 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11059,24 +11059,17 @@ intel_compare_link_m_n(const struct intel_link_m_n
*m_n,
static void __printf(3, 4)
pipe_config_err(bool adjust, const char *name, const char *format, ...)
{
- char *level;
- unsigned int category;
struct va_format vaf;
va_list args;
- if (adjust) {
- level = KERN_DEBUG;
- category = DRM_UT_KMS;
- } else {
- level = KERN_ERR;
- category = DRM_UT_NONE;
- }
-
va_start(args, format);
vaf.fmt = format;
vaf.va = &args;
- drm_printk(level, category, "mismatch in %s %pV", name, &vaf);
+ if (adjust)
+ drm_dbg(DRM_UT_KMS, "mismatch in %s %pV", name, &vaf);
+ else
+ drm_err("mismatch in %s %pV", name, &vaf);
va_end(args);
}
diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
index 2a4a42e59a47..3a40c5a3a5fa 100644
--- a/include/drm/drm_print.h
+++ b/include/drm/drm_print.h
@@ -200,9 +200,10 @@ __printf(6, 7)
void drm_dev_printk(const struct device *dev, const char *level,
unsigned int category, const char *function_name,
const char *prefix, const char *format, ...);
-__printf(3, 4)
-void drm_printk(const char *level, unsigned int category,
- const char *format, ...);
+__printf(2, 3)
+void drm_dbg(unsigned int category, const char *format, ...);
+__printf(1, 2)
+void drm_err(const char *format, ...);
/* Macros to make printk easier */
@@ -236,7 +237,7 @@ void drm_printk(const char *level, unsigned int category,
drm_dev_printk(dev, KERN_ERR, DRM_UT_NONE, __func__, " *ERROR*",\
fmt, ##__VA_ARGS__)
#define DRM_ERROR(fmt, ...)\
- drm_printk(KERN_ERR, DRM_UT_NONE, fmt, ##__VA_ARGS__)
+ drm_err(fmt, ##__VA_ARGS__)
/**
* Rate limited error output. Like DRM_ERROR() but won't flood the log.
@@ -279,40 +280,40 @@ void drm_printk(const char *level, unsigned int category,
drm_dev_printk(dev, KERN_DEBUG, DRM_UT_CORE, __func__, "", fmt, \
##args)
#define DRM_DEBUG(fmt, ...)\
- drm_printk(KERN_DEBUG, DRM_UT_CORE, fmt, ##__VA_ARGS__)
+ drm_dbg(DRM_UT_CORE, fmt, ##__VA_ARGS__)
#define DRM_DEV_DEBUG_DRIVER(dev, fmt, args...)
\
drm_dev_printk(dev, KERN_DEBUG, DRM_UT_DRIVER, __func__, "",\
[PATCH] drm/panel: rm68200: add backlight dependency
Like many other panel drivers, this one fails to build
when backlight support is disabled:
drivers/gpu/drm/panel/panel-raydium-rm68200.o: In function `rm68200_probe':
panel-raydium-rm68200.c:(.text+0x14a): undefined reference to
`devm_of_find_backlight'
This adds the appropriate dependency.
Fixes: 2b7ed18bed1a ("drm/panel: Add support for Raydium RM68200 panel driver")
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/panel/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 077bc58c1913..25682ff3449a 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -112,6 +112,7 @@ config DRM_PANEL_RAYDIUM_RM68200
tristate "Raydium RM68200 720x1280 DSI video mode panel"
depends on OF
depends on DRM_MIPI_DSI
+ depends on BACKLIGHT_CLASS_DEVICE
help
Say Y here if you want to enable support for Raydium RM68200
720x1280 DSI video mode panel.
--
2.9.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 00/10] splash screen on the stm32f769 disco board
On Tue, Mar 13, 2018 at 1:50 PM, Anatolij Gustschin wrote: > On Tue, 13 Mar 2018 16:23:10 +0100 > Daniel Vetter dan...@ffwll.ch wrote: > ... >> Shouldn't we patch the drivers/gpu/drm/stm driver instead of the >> drivers/video one? fbdev is kinda a dead end and not for adding new hw >> support ... > > this patch series adds display driver to U-Boot project, I don't know > why it was submitted to the Linux kernel and dri-devel mailing lists. > > Yannick, please don't send this to linux-kernel and dri-devel lists > and also please don't Cc kernel developers when resubmitting the > patch series. I couldn't agree more! I mentioned this on the previous confusing post (where I had the same objection as Daniel, before realizing this was just a poorly-documented, ill-targeted U-Boot patch series). Brian ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 1/5] drm/blend: Add a generic alpha property
Some drivers duplicate the logic to create a property to store a per-plane
alpha.
This is especially useful if we ever want to support extra protocols for
Wayland like:
https://lists.freedesktop.org/archives/wayland-devel/2017-August/034741.html
Let's create a helper in order to move that to the core.
Cc: Laurent Pinchart
Reviewed-by: Boris Brezillon
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/drm_atomic.c| 4 +++-
drivers/gpu/drm/drm_atomic_helper.c | 4 +++-
drivers/gpu/drm/drm_blend.c | 38 ++-
include/drm/drm_blend.h | 3 ++-
include/drm/drm_plane.h | 6 +-
5 files changed, 55 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 34b7d420e555..39204c88d2c5 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -753,6 +753,8 @@ static int drm_atomic_plane_set_property(struct drm_plane
*plane,
state->src_w = val;
} else if (property == config->prop_src_h) {
state->src_h = val;
+ } else if (property == plane->alpha_property) {
+ state->alpha = val;
} else if (property == plane->rotation_property) {
if (!is_power_of_2(val & DRM_MODE_ROTATE_MASK))
return -EINVAL;
@@ -818,6 +820,8 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
*val = state->src_w;
} else if (property == config->prop_src_h) {
*val = state->src_h;
+ } else if (property == plane->alpha_property) {
+ *val = state->alpha;
} else if (property == plane->rotation_property) {
*val = state->rotation;
} else if (property == plane->zpos_property) {
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 00c78c1c9681..ac4c3f18a0b1 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -3484,6 +3484,10 @@ void drm_atomic_helper_plane_reset(struct drm_plane
*plane)
if (plane->state) {
plane->state->plane = plane;
plane->state->rotation = DRM_MODE_ROTATE_0;
+
+ /* Reset the alpha value to fully opaque if it matters */
+ if (plane->alpha_property)
+ plane->state->alpha = plane->alpha_property->values[1];
}
}
EXPORT_SYMBOL(drm_atomic_helper_plane_reset);
diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
index 5a81e1b4c076..05eda2d57c77 100644
--- a/drivers/gpu/drm/drm_blend.c
+++ b/drivers/gpu/drm/drm_blend.c
@@ -88,6 +88,12 @@
* On top of this basic transformation additional properties can be exposed by
* the driver:
*
+ * alpha:
+ * Alpha is setup with drm_plane_create_alpha_property(). It controls the
+ * plane-wide opacity, from transparent (0) to opaque (0x). It can be
+ * combined with pixel alpha.
+ * The alpha value is represented as premultiplied alpha.
+ *
* rotation:
* Rotation is set up with drm_plane_create_rotation_property(). It adds a
* rotation and reflection step between the source and destination
rectangles.
@@ -106,6 +112,38 @@
*/
/**
+ * drm_plane_create_alpha_property - create a new alpha property
+ * @plane: drm plane
+ *
+ * This function creates a generic, mutable, alpha property and enables support
+ * for it in the DRM core. It is attached to @plane.
+ *
+ * The alpha property will be allowed to be within the bounds of 0
+ * (transparent) to 0x (opaque).
+ *
+ * Returns:
+ * 0 on success, negative error code on failure.
+ */
+int drm_plane_create_alpha_property(struct drm_plane *plane)
+{
+ struct drm_property *prop;
+
+ prop = drm_property_create_range(plane->dev, 0, "alpha",
+0, DRM_BLEND_ALPHA_OPAQUE);
+ if (!prop)
+ return -ENOMEM;
+
+ drm_object_attach_property(&plane->base, prop, DRM_BLEND_ALPHA_OPAQUE);
+ plane->alpha_property = prop;
+
+ if (plane->state)
+ plane->state->alpha = DRM_BLEND_ALPHA_OPAQUE;
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_plane_create_alpha_property);
+
+/**
* drm_plane_create_rotation_property - create a new rotation property
* @plane: drm plane
* @rotation: initial value of the rotation property
diff --git a/include/drm/drm_blend.h b/include/drm/drm_blend.h
index 17606026590b..330c561c4c11 100644
--- a/include/drm/drm_blend.h
+++ b/include/drm/drm_blend.h
@@ -36,6 +36,9 @@ static inline bool drm_rotation_90_or_270(unsigned int
rotation)
return rotation & (DRM_MODE_ROTATE_90 | DRM_MODE_ROTATE_270);
}
+#define DRM_BLEND_ALPHA_OPAQUE 0x
+
+int drm_plane_create_alpha_property(struct drm_plane *plane);
int drm_plane_create_rotation_property(struct drm_plane *plane,
unsigned int rotation,
unsigne
[PATCH v4 2/5] drm/atmel-hclcdc: Convert to the new generic alpha property
Now that we have support for per-plane alpha in the core, let's use it.
Acked-by: Boris Brezillon
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h| 13 +---
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 89 ++
2 files changed, 14 insertions(+), 88 deletions(-)
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
index ab32d5b268d2..60c937f42114 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
@@ -299,7 +299,6 @@ struct atmel_hlcdc_layer {
struct atmel_hlcdc_plane {
struct drm_plane base;
struct atmel_hlcdc_layer layer;
- struct atmel_hlcdc_plane_properties *properties;
};
static inline struct atmel_hlcdc_plane *
@@ -346,18 +345,6 @@ struct atmel_hlcdc_dc_desc {
};
/**
- * Atmel HLCDC Plane properties.
- *
- * This structure stores plane property definitions.
- *
- * @alpha: alpha blending (or transparency) property
- * @rotation: rotation property
- */
-struct atmel_hlcdc_plane_properties {
- struct drm_property *alpha;
-};
-
-/**
* Atmel HLCDC Display Controller.
*
* @desc: HLCDC Display Controller description
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
index e18800ed7cd1..73c875db45f4 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
@@ -31,7 +31,6 @@
* @src_y: y buffer position
* @src_w: buffer width
* @src_h: buffer height
- * @alpha: alpha blending of the plane
* @disc_x: x discard position
* @disc_y: y discard position
* @disc_w: discard width
@@ -54,8 +53,6 @@ struct atmel_hlcdc_plane_state {
uint32_t src_w;
uint32_t src_h;
- u8 alpha;
-
int disc_x;
int disc_y;
int disc_w;
@@ -385,7 +382,7 @@ atmel_hlcdc_plane_update_general_settings(struct
atmel_hlcdc_plane *plane,
cfg |= ATMEL_HLCDC_LAYER_LAEN;
else
cfg |= ATMEL_HLCDC_LAYER_GAEN |
- ATMEL_HLCDC_LAYER_GA(state->alpha);
+ ATMEL_HLCDC_LAYER_GA(state->base.alpha >> 8);
}
if (state->disc_h && state->disc_w)
@@ -553,7 +550,7 @@ atmel_hlcdc_plane_prepare_disc_area(struct drm_crtc_state
*c_state)
if (!ovl_s->fb ||
ovl_s->fb->format->has_alpha ||
- ovl_state->alpha != 255)
+ ovl_s->alpha != DRM_BLEND_ALPHA_OPAQUE)
continue;
/* TODO: implement a smarter hidden area detection */
@@ -829,51 +826,18 @@ static void atmel_hlcdc_plane_destroy(struct drm_plane *p)
drm_plane_cleanup(p);
}
-static int atmel_hlcdc_plane_atomic_set_property(struct drm_plane *p,
-struct drm_plane_state *s,
-struct drm_property *property,
-uint64_t val)
-{
- struct atmel_hlcdc_plane *plane = drm_plane_to_atmel_hlcdc_plane(p);
- struct atmel_hlcdc_plane_properties *props = plane->properties;
- struct atmel_hlcdc_plane_state *state =
- drm_plane_state_to_atmel_hlcdc_plane_state(s);
-
- if (property == props->alpha)
- state->alpha = val;
- else
- return -EINVAL;
-
- return 0;
-}
-
-static int atmel_hlcdc_plane_atomic_get_property(struct drm_plane *p,
- const struct drm_plane_state *s,
- struct drm_property *property,
- uint64_t *val)
-{
- struct atmel_hlcdc_plane *plane = drm_plane_to_atmel_hlcdc_plane(p);
- struct atmel_hlcdc_plane_properties *props = plane->properties;
- const struct atmel_hlcdc_plane_state *state =
- container_of(s, const struct atmel_hlcdc_plane_state, base);
-
- if (property == props->alpha)
- *val = state->alpha;
- else
- return -EINVAL;
-
- return 0;
-}
-
-static int atmel_hlcdc_plane_init_properties(struct atmel_hlcdc_plane *plane,
- struct atmel_hlcdc_plane_properties *props)
+static int atmel_hlcdc_plane_init_properties(struct atmel_hlcdc_plane *plane)
{
const struct atmel_hlcdc_layer_desc *desc = plane->layer.desc;
if (desc->type == ATMEL_HLCDC_OVERLAY_LAYER ||
- desc->type == ATMEL_HLCDC_CURSOR_LAYER)
- drm_object_attach_property(&plane->base.base,
- props->alpha, 255);
+ desc->type == ATMEL_HLCDC_CURSOR_LAYER) {
+ int ret;
+
+ ret = drm_plane_create_alpha_property(&plane->base);
+ if (ret)
+ return
[PATCH v4 5/5] drm/docs: Remove the rcar alpha from the csv file
Now that we moved the rcar-du DRM driver has been switched to the generic
alpha property, remove the former property documentation from the
deperecated CSV file.
Signed-off-by: Maxime Ripard
---
Documentation/gpu/kms-properties.csv | 1 -
1 file changed, 1 deletion(-)
diff --git a/Documentation/gpu/kms-properties.csv
b/Documentation/gpu/kms-properties.csv
index 6b28b014cb7d..07ed22ea3bd6 100644
--- a/Documentation/gpu/kms-properties.csv
+++ b/Documentation/gpu/kms-properties.csv
@@ -98,5 +98,4 @@ radeon,DVI-I,“coherent”,RANGE,"Min=0, Max=1",Connector,TBD
,,"""underscan vborder""",RANGE,"Min=0, Max=128",Connector,TBD
,Audio,“audio”,ENUM,"{ ""off"", ""on"", ""auto"" }",Connector,TBD
,FMT Dithering,“dither”,ENUM,"{ ""off"", ""on"" }",Connector,TBD
-rcar-du,Generic,"""alpha""",RANGE,"Min=0, Max=255",Plane,TBD
,,"""colorkey""",RANGE,"Min=0, Max=0x01ff",Plane,TBD
--
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 0/5] drm/blend: Support generic plane-wide alpha
Hi, This serie aims at enhancing the support for plane-wide alpha in the drivers that are implementing it at the moment, by turning it into a generic property and converting the drivers (rcar-du and atmel-hclcdc). It also introduces support for it in the sun4i driver. Let me know what you think, Maxime Changes from v3: - Rebased on current drm-misc-next - Made the alpha property a 16 bits property, and have the drivers drop the lowest 8 bits - Removed the csv documentation, and documented it in the doc instead Changes from v2: - Rebased on current drm-misc-next - Removed the patches already applied - Split the patch implementing the automatic pipe assignment in two Changes from v1: - Document the behaviour on concurrent usage of the alpha property and an alpha component in the format - Allowed for higher alpha values - Moved the alpha value from a helper to the struct drm_format_info - Collected tags - Rebased on current drm-misc-next Maxime Ripard (5): drm/blend: Add a generic alpha property drm/atmel-hclcdc: Convert to the new generic alpha property drm/rcar-du: Convert to the new generic alpha property drm/sun4i: Add support for plane alpha drm/docs: Remove the rcar alpha from the csv file Documentation/gpu/kms-properties.csv| 1 +- drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h| 13 +--- drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 89 ++ drivers/gpu/drm/drm_atomic.c| 4 +- drivers/gpu/drm/drm_atomic_helper.c | 4 +- drivers/gpu/drm/drm_blend.c | 38 - drivers/gpu/drm/rcar-du/rcar_du_drv.h | 1 +- drivers/gpu/drm/rcar-du/rcar_du_kms.c | 5 +- drivers/gpu/drm/rcar-du/rcar_du_plane.c | 15 +-- drivers/gpu/drm/rcar-du/rcar_du_plane.h | 2 +- drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 42 + drivers/gpu/drm/rcar-du/rcar_du_vsp.h | 2 +- drivers/gpu/drm/sun4i/sun4i_backend.c | 16 ++- drivers/gpu/drm/sun4i/sun4i_backend.h | 3 +- drivers/gpu/drm/sun4i/sun4i_layer.c | 2 +- include/drm/drm_blend.h | 3 +- include/drm/drm_plane.h | 6 +- 17 files changed, 96 insertions(+), 150 deletions(-) base-commit: 9c936b12f15019b38edb5f8bae77bb5b0046d1b7 -- git-series 0.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 3/5] drm/rcar-du: Convert to the new generic alpha property
Now that we have support for per-plane alpha in the core, let's use it.
Reviewed-by: Laurent Pinchart
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/rcar-du/rcar_du_drv.h | 1 +-
drivers/gpu/drm/rcar-du/rcar_du_kms.c | 5 +---
drivers/gpu/drm/rcar-du/rcar_du_plane.c | 15 +++--
drivers/gpu/drm/rcar-du/rcar_du_plane.h | 2 +-
drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 42 ++
drivers/gpu/drm/rcar-du/rcar_du_vsp.h | 2 +-
6 files changed, 9 insertions(+), 58 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.h
b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
index f400fde65a0c..dad87d449ef7 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
@@ -90,7 +90,6 @@ struct rcar_du_device {
struct rcar_du_vsp vsps[RCAR_DU_MAX_VSPS];
struct {
- struct drm_property *alpha;
struct drm_property *colorkey;
} props;
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
index 566d1a948c8f..e1b5a7b460cc 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
@@ -417,11 +417,6 @@ static int rcar_du_encoders_init(struct rcar_du_device
*rcdu)
static int rcar_du_properties_init(struct rcar_du_device *rcdu)
{
- rcdu->props.alpha =
- drm_property_create_range(rcdu->ddev, 0, "alpha", 0, 255);
- if (rcdu->props.alpha == NULL)
- return -ENOMEM;
-
/*
* The color key is expressed as an RGB888 triplet stored in a 32-bit
* integer in XRGB format. Bit 24 is used as a flag to disable (0)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_plane.c
b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
index 68556bd9dad2..c20f7ed48c8d 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_plane.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
@@ -423,7 +423,7 @@ static void rcar_du_plane_setup_mode(struct rcar_du_group
*rgrp,
rcar_du_plane_write(rgrp, index, PnALPHAR, PnALPHAR_ABIT_0);
else
rcar_du_plane_write(rgrp, index, PnALPHAR,
- PnALPHAR_ABIT_X | state->alpha);
+ PnALPHAR_ABIT_X | state->state.alpha >> 8);
pnmr = PnMR_BM_MD | state->format->pnmr;
@@ -692,11 +692,11 @@ static void rcar_du_plane_reset(struct drm_plane *plane)
state->hwindex = -1;
state->source = RCAR_DU_PLANE_MEMORY;
- state->alpha = 255;
state->colorkey = RCAR_DU_COLORKEY_NONE;
state->state.zpos = plane->type == DRM_PLANE_TYPE_PRIMARY ? 0 : 1;
plane->state = &state->state;
+ plane->state->alpha = DRM_BLEND_ALPHA_OPAQUE;
plane->state->plane = plane;
}
@@ -708,9 +708,7 @@ static int rcar_du_plane_atomic_set_property(struct
drm_plane *plane,
struct rcar_du_plane_state *rstate = to_rcar_plane_state(state);
struct rcar_du_device *rcdu = to_rcar_plane(plane)->group->dev;
- if (property == rcdu->props.alpha)
- rstate->alpha = val;
- else if (property == rcdu->props.colorkey)
+ if (property == rcdu->props.colorkey)
rstate->colorkey = val;
else
return -EINVAL;
@@ -726,9 +724,7 @@ static int rcar_du_plane_atomic_get_property(struct
drm_plane *plane,
container_of(state, const struct rcar_du_plane_state, state);
struct rcar_du_device *rcdu = to_rcar_plane(plane)->group->dev;
- if (property == rcdu->props.alpha)
- *val = rstate->alpha;
- else if (property == rcdu->props.colorkey)
+ if (property == rcdu->props.colorkey)
*val = rstate->colorkey;
else
return -EINVAL;
@@ -797,10 +793,9 @@ int rcar_du_planes_init(struct rcar_du_group *rgrp)
continue;
drm_object_attach_property(&plane->plane.base,
- rcdu->props.alpha, 255);
- drm_object_attach_property(&plane->plane.base,
rcdu->props.colorkey,
RCAR_DU_COLORKEY_NONE);
+ drm_plane_create_alpha_property(&plane->plane);
drm_plane_create_zpos_property(&plane->plane, 1, 1, 7);
}
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_plane.h
b/drivers/gpu/drm/rcar-du/rcar_du_plane.h
index 890321b4665d..5c19c69e4691 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_plane.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_plane.h
@@ -50,7 +50,6 @@ static inline struct rcar_du_plane *to_rcar_plane(struct
drm_plane *plane)
* @state: base DRM plane state
* @format: information about the pixel format used by the plane
* @hwindex: 0-based hardware plane index, -1 means unused
- * @alpha: value of the plane alpha property
* @colorkey: value of the plane colorkey property
*/
struct rcar_du_plane_state {
@@ -60,7
[PATCH v4 4/5] drm/sun4i: Add support for plane alpha
Our backend supports a per-plane alpha property. Support it through our new
helper.
Reviewed-by: Chen-Yu Tsai
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/sun4i_backend.c | 16 +---
drivers/gpu/drm/sun4i/sun4i_backend.h | 3 +++
drivers/gpu/drm/sun4i/sun4i_layer.c | 2 ++
3 files changed, 18 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c
b/drivers/gpu/drm/sun4i/sun4i_backend.c
index 092ade4ff6a5..98cd4a8a93ed 100644
--- a/drivers/gpu/drm/sun4i/sun4i_backend.c
+++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
@@ -186,6 +186,15 @@ int sun4i_backend_update_layer_formats(struct
sun4i_backend *backend,
DRM_DEBUG_DRIVER("Switching display backend interlaced mode %s\n",
interlaced ? "on" : "off");
+ val = SUN4I_BACKEND_ATTCTL_REG0_LAY_GLBALPHA(state->alpha >> 8);
+ if (state->alpha != DRM_BLEND_ALPHA_OPAQUE)
+ val |= SUN4I_BACKEND_ATTCTL_REG0_LAY_GLBALPHA_EN;
+ regmap_update_bits(backend->engine.regs,
+ SUN4I_BACKEND_ATTCTL_REG0(layer),
+ SUN4I_BACKEND_ATTCTL_REG0_LAY_GLBALPHA_MASK |
+ SUN4I_BACKEND_ATTCTL_REG0_LAY_GLBALPHA_EN,
+ val);
+
ret = sun4i_backend_drm_format_to_layer(fb->format->format, &val);
if (ret) {
DRM_DEBUG_DRIVER("Invalid format\n");
@@ -359,7 +368,7 @@ static int sun4i_backend_atomic_check(struct sunxi_engine
*engine,
DRM_DEBUG_DRIVER("Plane FB format is %s\n",
drm_get_format_name(fb->format->format,
&format_name));
- if (fb->format->has_alpha)
+ if (fb->format->has_alpha || (plane_state->alpha !=
DRM_BLEND_ALPHA_OPAQUE))
num_alpha_planes++;
DRM_DEBUG_DRIVER("Plane zpos is %d\n",
@@ -412,7 +421,8 @@ static int sun4i_backend_atomic_check(struct sunxi_engine
*engine,
}
/* We can't have an alpha plane at the lowest position */
- if (plane_states[0]->fb->format->has_alpha)
+ if (plane_states[0]->fb->format->has_alpha ||
+ (plane_states[0]->alpha != DRM_BLEND_ALPHA_OPAQUE))
return -EINVAL;
for (i = 1; i < num_planes; i++) {
@@ -424,7 +434,7 @@ static int sun4i_backend_atomic_check(struct sunxi_engine
*engine,
* The only alpha position is the lowest plane of the
* second pipe.
*/
- if (fb->format->has_alpha)
+ if (fb->format->has_alpha || (p_state->alpha !=
DRM_BLEND_ALPHA_OPAQUE))
current_pipe++;
s_state->pipe = current_pipe;
diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.h
b/drivers/gpu/drm/sun4i/sun4i_backend.h
index 52e77591186a..03294d5dd1a2 100644
--- a/drivers/gpu/drm/sun4i/sun4i_backend.h
+++ b/drivers/gpu/drm/sun4i/sun4i_backend.h
@@ -68,11 +68,14 @@
#define SUN4I_BACKEND_CKMIN_REG0x884
#define SUN4I_BACKEND_CKCFG_REG0x888
#define SUN4I_BACKEND_ATTCTL_REG0(l) (0x890 + (0x4 * (l)))
+#define SUN4I_BACKEND_ATTCTL_REG0_LAY_GLBALPHA_MASKGENMASK(31, 24)
+#define SUN4I_BACKEND_ATTCTL_REG0_LAY_GLBALPHA(x) ((x) << 24)
#define SUN4I_BACKEND_ATTCTL_REG0_LAY_PIPESEL_MASK BIT(15)
#define SUN4I_BACKEND_ATTCTL_REG0_LAY_PIPESEL(x) ((x) << 15)
#define SUN4I_BACKEND_ATTCTL_REG0_LAY_PRISEL_MASK GENMASK(11, 10)
#define SUN4I_BACKEND_ATTCTL_REG0_LAY_PRISEL(x)((x) <<
10)
#define SUN4I_BACKEND_ATTCTL_REG0_LAY_VDOENBIT(1)
+#define SUN4I_BACKEND_ATTCTL_REG0_LAY_GLBALPHA_EN BIT(0)
#define SUN4I_BACKEND_ATTCTL_REG1(l) (0x8a0 + (0x4 * (l)))
#define SUN4I_BACKEND_ATTCTL_REG1_LAY_HSCAFCT GENMASK(15, 14)
diff --git a/drivers/gpu/drm/sun4i/sun4i_layer.c
b/drivers/gpu/drm/sun4i/sun4i_layer.c
index 33ad377569ec..cf7857b8ac5c 100644
--- a/drivers/gpu/drm/sun4i/sun4i_layer.c
+++ b/drivers/gpu/drm/sun4i/sun4i_layer.c
@@ -37,6 +37,7 @@ static void sun4i_backend_layer_reset(struct drm_plane *plane)
if (state) {
plane->state = &state->state;
plane->state->plane = plane;
+ plane->state->alpha = DRM_BLEND_ALPHA_OPAQUE;
plane->state->zpos = layer->id;
}
}
@@ -163,6 +164,7 @@ static struct sun4i_layer *sun4i_layer_init_one(struct
drm_device *drm,
&sun4i_backend_layer_helper_funcs);
layer->backend = backend;
+ drm_plane_create_alpha_property(&layer->plane);
drm_plane_create_zpos_property(&layer->plane, 0, 0,
SUN4I_BACKEND_NUM_LAYERS - 1);
--
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedes
Re: [PATCH v3 1/6] cgroup: Allow registration and lookup of cgroup private data
Hello, Matt. cc'ing Roman and Alexei. On Tue, Mar 06, 2018 at 03:46:55PM -0800, Matt Roper wrote: > There are cases where other parts of the kernel may wish to store data > associated with individual cgroups without building a full cgroup > controller. Let's add interfaces to allow them to register and lookup > this private data for individual cgroups. > > A kernel system (e.g., a driver) that wishes to register private data > for a cgroup will do so by subclassing the 'struct cgroup_priv' > structure to describe the necessary data to store. Before registering a > private data structure to a cgroup, the caller should fill in the 'key' > and 'free' fields of the base cgroup_priv structure. > > * 'key' should be a unique void* that will act as a key for future >privdata lookups/removals. Note that this allows drivers to store >per-device private data for a cgroup by using a device pointer as a key. > > * 'free' should be a function pointer to a function that may be used >to destroy the private data. This function will be called >automatically if the underlying cgroup is destroyed. This feature turned out to have more users than I originally anticipated and bpf also wants something like this to track network states. The requirements are pretty similar but not quite the same. The extra requirements are... * Lookup must be really cheap. Probably using pointer hash or walking list isn't great, so maybe idr based lookup + RCU protected index table per cgroup? * It should support both regular memory and percpu pointers. Given that what cgroup does is pretty much cgroup:key -> pointer lookup, it's mostly about getting the interface right so that it's not too error-prone. Sorry about moving the goalpost. Thanks. -- tejun ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 3/6] cgroup: Introduce cgroup_permission()
On Tue, Mar 06, 2018 at 03:46:57PM -0800, Matt Roper wrote: > Non-controller kernel subsystems may base access restrictions for > cgroup-related syscalls/ioctls on a process' access to the cgroup. > Let's make it easy for other parts of the kernel to check these cgroup > permissions. I'm not sure about pulling in cgroup perms this way because cgroup access perms have more to it than the file and directory permissions. Can't this be restricted to root or some CAP? Thanks. -- tejun ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 2/6] cgroup: Introduce task_get_dfl_cgroup()
(cc'ing Roman)
Hello,
On Tue, Mar 06, 2018 at 03:46:56PM -0800, Matt Roper wrote:
> +static inline struct cgroup *
> +task_get_dfl_cgroup(struct task_struct *task)
> +{
> + struct cgroup *cgrp;
> +
> + mutex_lock(&cgroup_mutex);
> + cgrp = task_dfl_cgroup(task);
> + cgroup_get(cgrp);
> + mutex_unlock(&cgroup_mutex);
Heh, this is super heavy. Can't we do "rcu, try get, compare &
retry"?
Thanks.
--
tejun
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 102905] [R600] Miscompilation of TGSI to VLIW causes artifacts in Gallium Nine with Crysis2 bump mapping
https://bugs.freedesktop.org/show_bug.cgi?id=102905 --- Comment #4 from i...@yahoo.com --- (In reply to Roland Scheidegger from comment #3) > I've just sent a patch to mesa-dev which should > fix this, can you verify it works? Yes it works nicely. Can't wait to see the patch in git master. :) -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] [v2] drm/i915/pmu: avoid -Wmaybe-uninitialized warning
On Tue, Mar 13, 2018 at 6:46 PM, Tvrtko Ursulin
wrote:
>
> On 13/03/2018 16:19, Arnd Bergmann wrote:
>>
>> The conditional spinlock confuses gcc into thinking the 'flags' value
>> might contain uninitialized data:
>>
>> drivers/gpu/drm/i915/i915_pmu.c: In function '__i915_pmu_event_read':
>> arch/x86/include/asm/paravirt_types.h:573:3: error: 'flags' may be used
>> uninitialized in this function [-Werror=maybe-uninitialized]
>
>
> Hm, how does paravirt_types.h comes into the picture?
spin_unlock_irqrestore() calls arch_local_irq_restore()
>> The code is correct, but it's easy to see how the compiler gets confused
>> here. This avoids the problem by pulling the lock outside of the function
>> into its only caller.
>
>
> Is it specific gcc version, specific options, or specific kernel config that
> this happens?
Not gcc version specific (same result with gcc-4.9 through 8, didn't test
earlier versions that are currently broken).
> Strange that it hasn't been seen so far.
It seems to be a relatively rare 'randconfig' combination. Looking at
the preprocessed sources, I find:
static u64 get_rc6(struct drm_i915_private *i915, bool locked)
{
unsigned long flags;
u64 val;
if (intel_runtime_pm_get_if_in_use(i915)) {
val = __get_rc6(i915);
intel_runtime_pm_put(i915);
if (!locked)
do { do { ({ unsigned long __dummy; typeof(flags) __dummy2;
(void)(&__dummy == &__dummy2); 1; }); do { do { do { ({ unsigned long
__dummy; typeof(flags) __dummy2; (void)(&__dummy == &__dummy2); 1; });
flags = arch_local_irq_save(); } while (0); trace_hardirqs_off(); }
while (0); do { __asm__ __volatile__("": : :"memory"); do { (void)0;
(void)(spinlock_check(&i915->pmu.lock)); } while (0); } while (0); }
while (0); } while (0); } while (0);
if (val >= i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur) {
i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur = 0;
i915->pmu.sample[__I915_SAMPLE_RC6].cur = val;
} else {
val = i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur;
}
if (!locked)
spin_unlock_irqrestore(&i915->pmu.lock, flags);
} else {
struct pci_dev *pdev = i915->drm.pdev;
struct device *kdev = &pdev->dev;
unsigned long flags2;
# 455 "/git/arm-soc/drivers/gpu/drm/i915/i915_pmu.c"
if (!locked)
do { do { ({ unsigned long __dummy; typeof(flags) __dummy2;
(void)(&__dummy == &__dummy2); 1; }); do { do { do { ({ unsigned long
__dummy; typeof(flags) __dummy2; (void)(&__dummy == &__dummy2); 1; });
flags = arch_local_irq_save(); } while (0); trace_hardirqs_off(); }
while (0); do { __asm__ __volatile__("": : :"memory"); do { (void)0;
(void)(spinlock_check(&i915->pmu.lock)); } while (0); } while (0); }
while (0); } while (0); } while (0);
do { do { ({ unsigned long __dummy; typeof(flags2) __dummy2;
(void)(&__dummy == &__dummy2); 1; }); do { do { do { ({ unsigned long
__dummy; typeof(flags2) __dummy2; (void)(&__dummy == &__dummy2); 1;
}); flags2 = arch_local_irq_save(); } while (0); trace_hardirqs_off();
} while (0); do { __asm__ __volatile__("": : :"memory"); do { (void)0;
(void)(spinlock_check(&kdev->power.lock)); } while (0); } while (0); }
while (0); } while (0); } while (0);
if (!i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur)
i915->pmu.suspended_jiffies_last =
kdev->power.suspended_jiffies;
val = kdev->power.suspended_jiffies -
i915->pmu.suspended_jiffies_last;
val += jiffies - kdev->power.accounting_timestamp;
spin_unlock_irqrestore(&kdev->power.lock, flags2);
val = jiffies_to_nsecs(val);
val += i915->pmu.sample[__I915_SAMPLE_RC6].cur;
i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur = val;
if (!locked)
spin_unlock_irqrestore(&i915->pmu.lock, flags);
}
return val;
}
so it seems that the spin_lock_irqsave() is completely inlined through
a macro while the unlock is not, and the lock contains a memory barrier
(among other things) that might tell the compiler that the state of the
'locked' flag could changed underneath it.
It could also be the problem that arch_local_irq_restore() uses
__builtin_expect() in PVOP_TEST_NULL(op) when
CONFIG_PARAVIRT_DEBUG is enabled, see
static inline __attribute__((unused))
__attribute__((no_instrument_function))
__attribute__((no_instrument_function)) void
arch_local_irq_restore(unsigned long f)
{
({ unsigned long __eax = __eax, __edx = __edx, __ecx = __ecx;; do {
if (__builtin_expect(!!(pv_irq_ops.restore_fl.func == ((void *)0)),
0)) do { do { asm volatile("1:\t" ".byte 0x0f, 0x0b" "\n"
".pushsection __bug_table,\"aw\"\n" "2:\t" ".long " "1b" "\t#
bug_entry::bug_addr\n" "\t" ".long " "%c0" "\t# bug_entry::file\n"
"\t.word %c1" "\t# bug_entry::line\n" "\t.word %c2" "\t#
bug_entry::flags\n" "\t.org 2b+%c3\n" ".popsection" : : "i"
("/git/arm-soc/arch/x86/include/asm/paravirt.h"), "i" (783), "i" (0),
"i" (sizeof(struct bug_entry))); } while (0); do { ; asm volatile("");
__builtin_unreachable(); } while (0); } while (0); } while (0); asm
volatile("" "771:\n\t" "999:\n\t" ".pushsection
.discard.retpoline_safe\n
[radeon-alex:amd-staging-drm-next 699/881] sound/soc/amd/raven/pci-acp3x.c:58:8: error: implicit declaration of function 'pci_enable_msi'; did you mean 'pci_enable_sriov'?
Hi Maruthi,
FYI, the error/warning still remains.
tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head: 701dfa780797b7124ba47026a2f071d3f1c6fb2b
commit: 944b5289c92d9c1aad3760c012daf4cf2478381f [699/881] ASoC: AMD: enable
ACP3x drivers build
config: sh-allmodconfig (attached as .config)
compiler: sh4-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 944b5289c92d9c1aad3760c012daf4cf2478381f
# save the attached .config to linux build tree
make.cross ARCH=sh
All errors (new ones prefixed by >>):
sound/soc/amd/raven/pci-acp3x.c: In function 'snd_acp3x_probe':
>> sound/soc/amd/raven/pci-acp3x.c:58:8: error: implicit declaration of
>> function 'pci_enable_msi'; did you mean 'pci_enable_sriov'?
>> [-Werror=implicit-function-declaration]
ret = pci_enable_msi(pci);
^~
pci_enable_sriov
>> sound/soc/amd/raven/pci-acp3x.c:122:2: error: implicit declaration of
>> function 'pci_disable_msi'; did you mean 'pci_disable_sriov'?
>> [-Werror=implicit-function-declaration]
pci_disable_msi(pci);
^~~
pci_disable_sriov
sound/soc/amd/raven/pci-acp3x.c: At top level:
sound/soc/amd/raven/pci-acp3x.c:159:1: warning: data definition has no type
or storage class
module_pci_driver(acp3x_driver);
^
>> sound/soc/amd/raven/pci-acp3x.c:159:1: error: type defaults to 'int' in
>> declaration of 'module_pci_driver' [-Werror=implicit-int]
sound/soc/amd/raven/pci-acp3x.c:159:1: warning: parameter names (without
types) in function declaration
sound/soc/amd/raven/pci-acp3x.c:152:26: warning: 'acp3x_driver' defined but
not used [-Wunused-variable]
static struct pci_driver acp3x_driver = {
^~~~
cc1: some warnings being treated as errors
vim +58 sound/soc/amd/raven/pci-acp3x.c
e8f3716a Maruthi Srinivas Bayyavarapu 2017-03-27 29
e8f3716a Maruthi Srinivas Bayyavarapu 2017-03-27 30 static int
snd_acp3x_probe(struct pci_dev *pci,
e8f3716a Maruthi Srinivas Bayyavarapu 2017-03-27 31
const struct pci_device_id *pci_id)
e8f3716a Maruthi Srinivas Bayyavarapu 2017-03-27 32 {
e8f3716a Maruthi Srinivas Bayyavarapu 2017-03-27 33 int ret;
4a00d378 Maruthi Srinivas Bayyavarapu 2017-03-29 34 u32 addr, val;
e8f3716a Maruthi Srinivas Bayyavarapu 2017-03-27 35 struct acp3x_dev_data
*adata;
4a00d378 Maruthi Srinivas Bayyavarapu 2017-03-29 36 struct
platform_device_info pdevinfo;
4a00d378 Maruthi Srinivas Bayyavarapu 2017-03-29 37 unsigned int irqflags;
e8f3716a Maruthi Srinivas Bayyavarapu 2017-03-27 38
e8f3716a Maruthi Srinivas Bayyavarapu 2017-03-27 39 if
(pci_enable_device(pci)) {
e8f3716a Maruthi Srinivas Bayyavarapu 2017-03-27 40
dev_err(&pci->dev, "pci_enable_device failed\n");
e8f3716a Maruthi Srinivas Bayyavarapu 2017-03-27 41 return -ENODEV;
e8f3716a Maruthi Srinivas Bayyavarapu 2017-03-27 42 }
e8f3716a Maruthi Srinivas Bayyavarapu 2017-03-27 43
e8f3716a Maruthi Srinivas Bayyavarapu 2017-03-27 44 ret =
pci_request_regions(pci, "AMD ACP3x audio");
e8f3716a Maruthi Srinivas Bayyavarapu 2017-03-27 45 if (ret < 0) {
e8f3716a Maruthi Srinivas Bayyavarapu 2017-03-27 46
dev_err(&pci->dev, "pci_request_regions failed\n");
e8f3716a Maruthi Srinivas Bayyavarapu 2017-03-27 47 goto
disable_pci;
e8f3716a Maruthi Srinivas Bayyavarapu 2017-03-27 48 }
e8f3716a Maruthi Srinivas Bayyavarapu 2017-03-27 49
e8f3716a Maruthi Srinivas Bayyavarapu 2017-03-27 50 adata =
devm_kzalloc(&pci->dev, sizeof(struct acp3x_dev_data),
e8f3716a Maruthi Srinivas Bayyavarapu 2017-03-27 51
GFP_KERNEL);
e8f3716a Maruthi Srinivas Bayyavarapu 2017-03-27 52 if (adata == NULL) {
e8f3716a Maruthi Srinivas Bayyavarapu 2017-03-27 53 ret = -ENOMEM;
e8f3716a Maruthi Srinivas Bayyavarapu 2017-03-27 54 goto
release_regions;
e8f3716a Maruthi Srinivas Bayyavarapu 2017-03-27 55 }
e8f3716a Maruthi Srinivas Bayyavarapu 2017-03-27 56
4a00d378 Maruthi Srinivas Bayyavarapu 2017-03-29 57 /* check for msi
interrupt support */
4a00d378 Maruthi Srinivas Bayyavarapu 2017-03-29 @58 ret =
pci_enable_msi(pci);
4a00d378 Maruthi Srinivas Bayyavarapu 2017-03-29 59 if (ret)
4a00d378 Maruthi Srinivas Bayyavarapu 2017-03-29 60 /* msi is not
enabled */
4a00d378 Maruthi Srinivas Bayyavarapu 2017-03-29 61 irqflags =
IRQF_SHARED;
4a00d378 Maruthi Srinivas Bayyavarapu 2017-03-29 62 else
4a00d378 Maruthi Srinivas Bayyavarapu 2017-03-29 63 /* msi is
enabled */
4a00d378 Maruthi Srinivas Bayyavarapu 2017-03-29 64 irqflags = 0;
4a00d378 Maruthi Srinivas Bayyavarapu 2017-03-29 65
e8f3716a Maruthi S
Re: [PATCH 3/3] drm: Store the calculated vrefresh in the user mode
Op 13-03-18 om 16:07 schreef Ville Syrjala: > From: Ville Syrjälä > > Ignore the vrefresh in the mode the user passed in and instead > calculate the value based on the actual timings. This way we can > actually trust mode->vrefresh to some degree. > > Or should we compare the user's idea of vrefresh with the one > we get from the timings and return an error if they differ? We > can't really be sure what the user is asking in that case. > > Signed-off-by: Ville Syrjälä > --- > drivers/gpu/drm/drm_modes.c | 8 +++- > 1 file changed, 7 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c > index f6b7c0e36a1a..021526ec6fa0 100644 > --- a/drivers/gpu/drm/drm_modes.c > +++ b/drivers/gpu/drm/drm_modes.c > @@ -1609,7 +1609,11 @@ int drm_mode_convert_umode(struct drm_device *dev, > out->vsync_end = in->vsync_end; > out->vtotal = in->vtotal; > out->vscan = in->vscan; > - out->vrefresh = in->vrefresh; > + /* > + * Ignore what the user is saying here and instead > + * calculate vrefresh based on the actual timings. > + */ > + out->vrefresh = 0; > out->flags = in->flags; > out->type = in->type; > strncpy(out->name, in->name, DRM_DISPLAY_MODE_LEN); > @@ -1619,6 +1623,8 @@ int drm_mode_convert_umode(struct drm_device *dev, > if (out->status != MODE_OK) > return -EINVAL; > > + out->vrefresh = drm_mode_vrefresh(out); > + > drm_mode_set_crtcinfo(out, CRTC_INTERLACE_HALVE_V); > > return 0; Could we also get this with dim fixes tags dc911f5bd8aa, so we can backport the alt mode handling patch? And update the documentation about vrefresh, that you can retrieve it with drm_mode_vrefresh? ~Maarten ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 102646] [dc] Screen flickering under amdgpu-experimental [buggy auto power profile]
https://bugs.freedesktop.org/show_bug.cgi?id=102646 --- Comment #27 from Ruben Harutyunyan --- Hmm. I guess I got deceived by `CONFIG_DRM_AMD_DC=y` being available in that commit and logs like `dc_link_detect` and `dc_link_handle_hpd_rx_irq` that didn't show up before. Sorry about that! -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 198123] Console is the wrong color at boot with radeon 6670
https://bugzilla.kernel.org/show_bug.cgi?id=198123 sh...@tuta.io changed: What|Removed |Added CC||sh...@tuta.io --- Comment #35 from sh...@tuta.io --- Has the cause of this issue been identified/confirmed? On boot I have grey console background instead of black. Linux 4.15.8-1-ARCH x86_64 1002:6758 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Turks XT [Radeon HD 6670/7670] -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm 2/2] meson: detect alloca.h
Quoting Eric Engestrom (2018-03-13 07:54:12)
> amdgpu makes use of it
>
> Signed-off-by: Eric Engestrom
> ---
> meson.build | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meson.build b/meson.build
> index 3a33928d02a6dce5f075..f7986af9bb5259be5da5 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -186,7 +186,7 @@ else
>dep_rt = []
> endif
> dep_m = cc.find_library('m', required : false)
> -foreach header : ['sys/sysctl.h', 'sys/select.h']
> +foreach header : ['sys/sysctl.h', 'sys/select.h', 'alloca.h']
>if cc.compiles('#include <@0@>'.format(header), name : '@0@
> works'.format(header))
> config.set10('HAVE_' + header.underscorify().to_upper(), true)
>endif
> --
> Cheers,
> Eric
>
for the series:
Reviewed-by: Dylan Baker
signature.asc
Description: signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH hwc v1] [RFC] drm_hwcomposer: Flatten composition using writeback connector
Hey Alexandru, On Tue, Mar 13, 2018 at 5:21 PM, Alexandru Gheorghe wrote: > This patchset tries to add support for using writeback connector to > flatten a scene when it doesn't change for a while. This idea had > been floated around on IRC here [1] and here [2]. > > 2. Heuristic for triggering the flattening. > I just created a VSyncWorker which will trigger the flattening of the > scene if it doesn't change for 60 consecutive vsyncs. The countdown > gets reset every time ValidateDisplay is called. This is a relatively > basic heuristic, so I'm open to suggestions. I think when Android deems that the display is sufficiently idle, it will disable VSync through setVsyncEnabled. Presumably we could just trigger the flattening on an enabled -> disabled transition? Thanks, Stefan ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [DPU PATCH 08/11] drm/msm: Remove hand-rolled out fences
On 2018-03-12 13:30, Sean Paul wrote:
On Fri, Mar 02, 2018 at 04:44:55PM -0800, Jeykumar Sankaran wrote:
On 2018-02-28 11:19, Sean Paul wrote:
> Remove release/output/retire fences from the dpu driver. These are
> already available via drm core's OUT_FENCE property.
>
> Change-Id: Id4238d0b5457f2c8ee2e87bb7814e1850a573623
> Signed-off-by: Sean Paul
Reviewed-by: Jeykumar Sankaran
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_connector.c | 66 +--
> drivers/gpu/drm/msm/disp/dpu1/dpu_connector.h | 23 ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 178
+++---
> drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h | 28 ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 3 -
> drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h | 4 +-
> .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h | 8 -
> .../drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 73 +--
> .../drm/msm/disp/dpu1/dpu_encoder_phys_vid.c | 19 --
> .../drm/msm/disp/dpu1/dpu_encoder_phys_wb.c | 12 +-
> drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 30 ---
> drivers/gpu/drm/msm/msm_drv.h | 3 -
> 12 files changed, 36 insertions(+), 411 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_connector.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_connector.c
> index 57b8627ef418..cc5bfa862cb7 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_connector.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_connector.c
> @@ -521,7 +521,6 @@ static void dpu_connector_destroy(struct
> drm_connector
> *connector)
>backlight_device_unregister(c_conn->bl_device);
>drm_connector_unregister(connector);
>mutex_destroy(&c_conn->lock);
> - dpu_fence_deinit(&c_conn->retire_fence);
>drm_connector_cleanup(connector);
>kfree(c_conn);
> }
> @@ -906,12 +905,9 @@ static int
dpu_connector_atomic_get_property(struct
> drm_connector *connector,
>c_state = to_dpu_connector_state(state);
>
>idx = msm_property_index(&c_conn->property_info, property);
> - if (idx == CONNECTOR_PROP_RETIRE_FENCE)
> - rc = dpu_fence_create(&c_conn->retire_fence, val, 0);
> - else
> - /* get cached property value */
> - rc = msm_property_atomic_get(&c_conn->property_info,
> - &c_state->property_state, property, val);
> + /* get cached property value */
> + rc = msm_property_atomic_get(&c_conn->property_info,
> + &c_state->property_state, property, val);
>
>/* allow for custom override */
>if (c_conn->ops.get_property)
> @@ -923,39 +919,6 @@ static int
dpu_connector_atomic_get_property(struct
> drm_connector *connector,
>return rc;
> }
>
> -void dpu_connector_prepare_fence(struct drm_connector *connector)
> -{
> - if (!connector) {
> - DPU_ERROR("invalid connector\n");
> - return;
> - }
> -
> - dpu_fence_prepare(&to_dpu_connector(connector)->retire_fence);
> -}
> -
> -void dpu_connector_complete_commit(struct drm_connector *connector,
> - ktime_t ts)
> -{
> - if (!connector) {
> - DPU_ERROR("invalid connector\n");
> - return;
> - }
> -
> - /* signal connector's retire fence */
> - dpu_fence_signal(&to_dpu_connector(connector)->retire_fence, ts,
> false);
> -}
> -
> -void dpu_connector_commit_reset(struct drm_connector *connector,
> ktime_t
> ts)
> -{
> - if (!connector) {
> - DPU_ERROR("invalid connector\n");
> - return;
> - }
> -
> - /* signal connector's retire fence */
> - dpu_fence_signal(&to_dpu_connector(connector)->retire_fence, ts,
> true);
> -}
> -
> static enum drm_connector_status
> dpu_connector_detect(struct drm_connector *connector, bool force)
> {
> @@ -1214,26 +1177,19 @@ struct drm_connector
*dpu_connector_init(struct
> drm_device *dev,
>"conn%u",
>c_conn->base.base.id);
>
> - rc = dpu_fence_init(&c_conn->retire_fence, c_conn->name,
> - c_conn->base.base.id);
> - if (rc) {
> - DPU_ERROR("failed to init fence, %d\n", rc);
> - goto error_cleanup_conn;
> - }
> -
>mutex_init(&c_conn->lock);
>
>rc = drm_mode_connector_attach_encoder(&c_conn->base, encoder);
>if (rc) {
>DPU_ERROR("failed to attach encoder to connector, %d\n",
> rc);
> - goto error_cleanup_fence;
> + goto error_cleanup_conn;
>}
>
> #ifdef CONFIG_DRM_MSM_DSI_STAGING
>rc = dpu_backlight_setup(c_conn, dev);
>if (rc) {
>DPU_ERROR("failed to setup backlight, rc=%d\n", rc);
> - goto error_cleanup_fence;
> + goto error_cleanup_conn;
>}
> #endif
>
> @@ -1248,7 +1204,7 @@ struct drm_connector *dpu_connector_init(struct
> drm_device *dev,
>if (!info) {
>DPU_ERROR("failed to allocate info buffer\n");
>rc = -ENOMEM;
> - goto error_cleanup_fence;
> + goto error_cleanup_conn;
>}
>
>dpu_kms_info_reset(info);
> @@ -12
Re: [DPU PATCH 01/11] drm/msm: Skip seamless disables in crtc/encoder
On 2018-03-12 13:14, Sean Paul wrote:
On Fri, Mar 02, 2018 at 04:04:24PM -0800, jsa...@codeaurora.org wrote:
On 2018-02-28 11:18, Sean Paul wrote:
> Instead of duplicating whole swaths of atomic helper functions (which
> are already out-of-date), just skip the encoder/crtc disables in the
> .disable hooks.
>
> Change-Id: I7bd9183ae60624204fb1de9550656b776efc7202
> Signed-off-by: Sean Paul
Reviewed-by: Jeykumar Sankaran
Can you consider getting rid of these checks?
Do you mean the Change-Id? Yeah, I forgot to strip them out before
sending, I'll
make sure I clean it up before I apply.
Actually, I meant removing the seamless check flags that you are moving
to
encode/crtc. But you can ignore that, I am planning to submit a seperate
change to remove the support from the whole pipeline.
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c| 8 +
> drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 8 +
> drivers/gpu/drm/msm/msm_atomic.c| 185
+---
> 3 files changed, 17 insertions(+), 184 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> index 3cdf1e3d9d96..a3ab6ed2bf1d 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> @@ -3393,6 +3393,7 @@ static void dpu_crtc_disable(struct drm_crtc
> *crtc)
> {
>struct dpu_crtc *dpu_crtc;
>struct dpu_crtc_state *cstate;
> + struct drm_display_mode *mode;
>struct drm_encoder *encoder;
>struct msm_drm_private *priv;
>unsigned long flags;
> @@ -3407,8 +3408,15 @@ static void dpu_crtc_disable(struct drm_crtc
> *crtc)
>}
>dpu_crtc = to_dpu_crtc(crtc);
>cstate = to_dpu_crtc_state(crtc->state);
> + mode = &cstate->base.adjusted_mode;
>priv = crtc->dev->dev_private;
>
> + if (msm_is_mode_seamless(mode) || msm_is_mode_seamless_vrr(mode)
> ||
> + msm_is_mode_seamless_dms(mode)) {
> + DPU_DEBUG("Seamless mode is being applied, skip
> disable\n");
> + return;
> + }
> +
Another topic of discussion which should be brought up with dri-devel.
May not be common in PC world, but there are a handful of mobile OEM's
using panels which supports more than one resolution. Primary use
cases
involve "seamless" switching to optimized display resolution when
streaming content changes resolutions or rendering lossless data.
Yeah, I think we can do this under the covers if the hardware supports
it
such
as this patch. We could probably do a better job of making this useful
for
other
drivers, but I was really just trying to get the seamless stuff out of
the
way
so we don't need to roll our own atomic commit.
Sean
Jeykumar S.
>DPU_DEBUG("crtc%d\n", crtc->base.id);
>
>if (dpu_kms_is_suspend_state(crtc->dev))
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> index 3d168fa09f3f..28ceb589ee40 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> @@ -2183,6 +2183,7 @@ static void dpu_encoder_virt_disable(struct
> drm_encoder *drm_enc)
>struct dpu_encoder_virt *dpu_enc = NULL;
>struct msm_drm_private *priv;
>struct dpu_kms *dpu_kms;
> + struct drm_display_mode *mode;
>int i = 0;
>
>if (!drm_enc) {
> @@ -2196,6 +2197,13 @@ static void dpu_encoder_virt_disable(struct
> drm_encoder *drm_enc)
>return;
>}
>
> + mode = &drm_enc->crtc->state->adjusted_mode;
> + if (msm_is_mode_seamless(mode) || msm_is_mode_seamless_vrr(mode)
> ||
> + msm_is_mode_seamless_dms(mode)) {
> + DPU_DEBUG("Seamless mode is being applied, skip
> disable\n");
> + return;
> + }
> +
>dpu_enc = to_dpu_encoder_virt(drm_enc);
>DPU_DEBUG_ENC(dpu_enc, "\n");
>
> diff --git a/drivers/gpu/drm/msm/msm_atomic.c
> b/drivers/gpu/drm/msm/msm_atomic.c
> index 46536edb72ee..5cfb80345052 100644
> --- a/drivers/gpu/drm/msm/msm_atomic.c
> +++ b/drivers/gpu/drm/msm/msm_atomic.c
> @@ -84,189 +84,6 @@ static void msm_atomic_wait_for_commit_done(
>}
> }
>
> -static void
> -msm_disable_outputs(struct drm_device *dev, struct drm_atomic_state
> *old_state)
> -{
> - struct drm_connector *connector;
> - struct drm_connector_state *old_conn_state, *new_conn_state;
> - struct drm_crtc *crtc;
> - struct drm_crtc_state *old_crtc_state, *new_crtc_state;
> - int i;
> -
> - for_each_oldnew_connector_in_state(old_state, connector,
> old_conn_state, new_conn_state, i) {
> - const struct drm_encoder_helper_funcs *funcs;
> - struct drm_encoder *encoder;
> - struct drm_crtc_state *old_crtc_state;
> - unsigned int crtc_idx;
> -
> - /*
> - * Shut down everything that's in the changeset and
> currently
> - * still on. So need to check the old, saved state.
> - */
> - if (!old_conn_state->crtc)
> - continue;
> -
> - crtc_idx = drm_c
[PATCH v2 11/11] drm: rcar-du: Support interlaced video output through vsp1
Use the newly exposed VSP1 interface to enable interlaced frame support through the VSP1 lif pipelines. Signed-off-by: Kieran Bingham --- drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 1 + drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 3 +++ 2 files changed, 4 insertions(+) diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c index 5685d5af6998..9854d9deb944 100644 --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c @@ -248,6 +248,7 @@ static void rcar_du_crtc_set_display_timing(struct rcar_du_crtc *rcrtc) /* Signal polarities */ value = ((mode->flags & DRM_MODE_FLAG_PVSYNC) ? DSMR_VSL : 0) | ((mode->flags & DRM_MODE_FLAG_PHSYNC) ? DSMR_HSL : 0) + | ((mode->flags & DRM_MODE_FLAG_INTERLACE) ? DSMR_ODEV : 0) | DSMR_DIPM_DISP | DSMR_CSPM; rcar_du_crtc_write(rcrtc, DSMR, value); diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c index 2c260c33840b..5e47daef8bd2 100644 --- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c +++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c @@ -178,6 +178,9 @@ static void rcar_du_vsp_plane_setup(struct rcar_du_vsp_plane *plane) }; unsigned int i; + cfg.interlaced = !!(plane->plane.state->crtc->mode.flags + & DRM_MODE_FLAG_INTERLACE); + cfg.src.left = state->state.src.x1 >> 16; cfg.src.top = state->state.src.y1 >> 16; cfg.src.width = drm_rect_width(&state->state.src) >> 16; -- git-series 0.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 07/11] media: vsp1: Use header display lists for all WPF outputs linked to the DU
Header mode display lists are now supported on all WPF outputs. To
support extended headers and auto-fld capabilities for interlaced mode
handling only header mode display lists can be used.
Disable the headerless display list configuration, and remove the dead
code.
Signed-off-by: Kieran Bingham
---
drivers/media/platform/vsp1/vsp1_dl.c | 107 ++-
1 file changed, 27 insertions(+), 80 deletions(-)
diff --git a/drivers/media/platform/vsp1/vsp1_dl.c
b/drivers/media/platform/vsp1/vsp1_dl.c
index 680eedb6fc9f..5f5706f8a84c 100644
--- a/drivers/media/platform/vsp1/vsp1_dl.c
+++ b/drivers/media/platform/vsp1/vsp1_dl.c
@@ -98,7 +98,7 @@ struct vsp1_dl_body_pool {
* struct vsp1_dl_list - Display list
* @list: entry in the display list manager lists
* @dlm: the display list manager
- * @header: display list header, NULL for headerless lists
+ * @header: display list header
* @dma: DMA address for the header
* @body0: first display list body
* @bodies: list of extra display list bodies
@@ -119,15 +119,9 @@ struct vsp1_dl_list {
struct list_head chain;
};
-enum vsp1_dl_mode {
- VSP1_DL_MODE_HEADER,
- VSP1_DL_MODE_HEADERLESS,
-};
-
/**
* struct vsp1_dl_manager - Display List manager
* @index: index of the related WPF
- * @mode: display list operation mode (header or headerless)
* @singleshot: execute the display list in single-shot mode
* @vsp1: the VSP1 device
* @lock: protects the free, active, queued, pending and gc_bodies lists
@@ -139,7 +133,6 @@ enum vsp1_dl_mode {
*/
struct vsp1_dl_manager {
unsigned int index;
- enum vsp1_dl_mode mode;
bool singleshot;
struct vsp1_device *vsp1;
@@ -320,6 +313,7 @@ static struct vsp1_dl_list *vsp1_dl_list_alloc(struct
vsp1_dl_manager *dlm,
struct vsp1_dl_body_pool *pool)
{
struct vsp1_dl_list *dl;
+ size_t header_offset;
dl = kzalloc(sizeof(*dl), GFP_KERNEL);
if (!dl)
@@ -332,16 +326,15 @@ static struct vsp1_dl_list *vsp1_dl_list_alloc(struct
vsp1_dl_manager *dlm,
dl->body0 = vsp1_dl_body_get(pool);
if (!dl->body0)
return NULL;
- if (dlm->mode == VSP1_DL_MODE_HEADER) {
- size_t header_offset = dl->body0->max_entries
-* sizeof(*dl->body0->entries);
- dl->header = ((void *)dl->body0->entries) + header_offset;
- dl->dma = dl->body0->dma + header_offset;
+ header_offset = dl->body0->max_entries
+* sizeof(*dl->body0->entries);
- memset(dl->header, 0, sizeof(*dl->header));
- dl->header->lists[0].addr = dl->body0->dma;
- }
+ dl->header = ((void *)dl->body0->entries) + header_offset;
+ dl->dma = dl->body0->dma + header_offset;
+
+ memset(dl->header, 0, sizeof(*dl->header));
+ dl->header->lists[0].addr = dl->body0->dma;
return dl;
}
@@ -473,16 +466,9 @@ struct vsp1_dl_body *vsp1_dl_list_get_body0(struct
vsp1_dl_list *dl)
*
* The reference must be explicitly released by a call to vsp1_dl_body_put()
* when the body isn't needed anymore.
- *
- * Additional bodies are only usable for display lists in header mode.
- * Attempting to add a body to a header-less display list will return an error.
*/
int vsp1_dl_list_add_body(struct vsp1_dl_list *dl, struct vsp1_dl_body *dlb)
{
- /* Multi-body lists are only available in header mode. */
- if (dl->dlm->mode != VSP1_DL_MODE_HEADER)
- return -EINVAL;
-
refcount_inc(&dlb->refcnt);
list_add_tail(&dlb->list, &dl->bodies);
@@ -503,17 +489,10 @@ int vsp1_dl_list_add_body(struct vsp1_dl_list *dl, struct
vsp1_dl_body *dlb)
* Adding a display list to a chain passes ownership of the display list to
* the head display list item. The chain is released when the head dl item is
* put back with __vsp1_dl_list_put().
- *
- * Chained display lists are only usable in header mode. Attempts to add a
- * display list to a chain in header-less mode will return an error.
*/
int vsp1_dl_list_add_chain(struct vsp1_dl_list *head,
struct vsp1_dl_list *dl)
{
- /* Chained lists are only available in header mode. */
- if (head->dlm->mode != VSP1_DL_MODE_HEADER)
- return -EINVAL;
-
head->has_chain = true;
list_add_tail(&dl->chain, &head->chain);
return 0;
@@ -581,17 +560,10 @@ static bool vsp1_dl_list_hw_update_pending(struct
vsp1_dl_manager *dlm)
return false;
/*
-* Check whether the VSP1 has taken the update. In headerless mode the
-* hardware indicates this by clearing the UPD bit in the DL_BODY_SIZE
-* register, and in header mode by clearing the UPDHDR bit in the CMD
-* register.
+* Check whether the VSP1 has taken the update. In header mode by
+* cle
[PATCH v2 10/11] media: vsp1: Support Interlaced display pipelines
Calculate the top and bottom fields for the interlaced frames and
utilise the extended display list command feature to implement the
auto-field operations. This allows the DU to update the VSP2 registers
dynamically based upon the currently processing field.
Signed-off-by: Kieran Bingham
---
v2:
- fix erroneous BIT value which enabled interlaced
- fix field handling at frame_end interrupt
drivers/media/platform/vsp1/vsp1_dl.c | 10 -
drivers/media/platform/vsp1/vsp1_drm.c | 11 -
drivers/media/platform/vsp1/vsp1_regs.h | 1 +-
drivers/media/platform/vsp1/vsp1_rpf.c | 72 --
drivers/media/platform/vsp1/vsp1_rwpf.h | 1 +-
include/media/vsp1.h| 1 +-
6 files changed, 93 insertions(+), 3 deletions(-)
diff --git a/drivers/media/platform/vsp1/vsp1_dl.c
b/drivers/media/platform/vsp1/vsp1_dl.c
index d8392bd866f1..08715ce6db1e 100644
--- a/drivers/media/platform/vsp1/vsp1_dl.c
+++ b/drivers/media/platform/vsp1/vsp1_dl.c
@@ -889,7 +889,9 @@ void vsp1_dl_list_commit(struct vsp1_dl_list *dl)
*/
bool vsp1_dlm_irq_frame_end(struct vsp1_dl_manager *dlm)
{
+ struct vsp1_device *vsp1 = dlm->vsp1;
bool completed = false;
+ u32 status = vsp1_read(vsp1, VI6_STATUS);
spin_lock(&dlm->lock);
@@ -914,6 +916,14 @@ bool vsp1_dlm_irq_frame_end(struct vsp1_dl_manager *dlm)
goto done;
/*
+* Progressive streams report only TOP fields. If we have a BOTTOM
+* field, we are interlaced, and expect the frame to complete on the
+* next frame end interrupt.
+*/
+ if (status & VI6_STATUS_FLD_STD(dlm->index))
+ goto done;
+
+ /*
* The device starts processing the queued display list right after the
* frame end interrupt. The display list thus becomes active.
*/
diff --git a/drivers/media/platform/vsp1/vsp1_drm.c
b/drivers/media/platform/vsp1/vsp1_drm.c
index 0459b970e9da..a714c53601b6 100644
--- a/drivers/media/platform/vsp1/vsp1_drm.c
+++ b/drivers/media/platform/vsp1/vsp1_drm.c
@@ -368,6 +368,17 @@ int vsp1_du_atomic_update(struct device *dev, unsigned int
pipe_index,
return -EINVAL;
}
+ if (!(vsp1_feature(vsp1, VSP1_HAS_EXT_DL)) && cfg->interlaced) {
+ /*
+* Interlaced support requires extended display lists to
+* provide the auto-fld feature with the DU.
+*/
+ dev_dbg(vsp1->dev, "Interlaced unsupported on this output\n");
+ return -EINVAL;
+ }
+
+ rpf->interlaced = cfg->interlaced;
+
rpf->fmtinfo = fmtinfo;
rpf->format.num_planes = fmtinfo->planes;
rpf->format.plane_fmt[0].bytesperline = cfg->pitch;
diff --git a/drivers/media/platform/vsp1/vsp1_regs.h
b/drivers/media/platform/vsp1/vsp1_regs.h
index 43ad68ff3167..e2dffbe82809 100644
--- a/drivers/media/platform/vsp1/vsp1_regs.h
+++ b/drivers/media/platform/vsp1/vsp1_regs.h
@@ -31,6 +31,7 @@
#define VI6_SRESET_SRTS(n) (1 << (n))
#define VI6_STATUS 0x0038
+#define VI6_STATUS_FLD_STD(n) (1 << ((n) + 28))
#define VI6_STATUS_SYS_ACT(n) (1 << ((n) + 8))
#define VI6_WPF_IRQ_ENB(n) (0x0048 + (n) * 12)
diff --git a/drivers/media/platform/vsp1/vsp1_rpf.c
b/drivers/media/platform/vsp1/vsp1_rpf.c
index 67f2fb3e0611..86ac8f488b7a 100644
--- a/drivers/media/platform/vsp1/vsp1_rpf.c
+++ b/drivers/media/platform/vsp1/vsp1_rpf.c
@@ -24,6 +24,20 @@
#define RPF_MAX_WIDTH 8190
#define RPF_MAX_HEIGHT 8190
+/* Pre extended display list command data structure */
+struct vsp1_extcmd_auto_fld_body {
+ u32 top_y0;
+ u32 bottom_y0;
+ u32 top_c0;
+ u32 bottom_c0;
+ u32 top_c1;
+ u32 bottom_c1;
+ u32 reserved0;
+ u32 reserved1;
+} __packed;
+
+#define VSP1_DL_EXT_AUTOFLD_INTBIT(0)
+
/*
-
* Device Access
*/
@@ -68,6 +82,14 @@ static void rpf_configure_stream(struct vsp1_entity *entity,
pstride |= format->plane_fmt[1].bytesperline
<< VI6_RPF_SRCM_PSTRIDE_C_SHIFT;
+ /*
+* pstride has both STRIDE_Y and STRIDE_C, but multiplying the whole
+* of pstride by 2 is conveniently OK here as we are multiplying both
+* values.
+*/
+ if (rpf->interlaced)
+ pstride *= 2;
+
vsp1_rpf_write(rpf, dlb, VI6_RPF_SRCM_PSTRIDE, pstride);
/* Format */
@@ -104,6 +126,9 @@ static void rpf_configure_stream(struct vsp1_entity *entity,
top = compose->top;
}
+ if (rpf->interlaced)
+ top /= 2;
+
vsp1_rpf_write(rpf, dlb, VI6_RPF_LOC,
(left << VI6_RPF_LOC_HCOORD_SHIFT) |
(top << VI6_RPF_LOC_VCOORD_SHIFT))
[PATCH v2 09/11] media: vsp1: Provide support for extended command pools
VSPD and VSP-DL devices can provide extended display lists supporting
extended command display list objects.
These extended commands require their own dma memory areas for a header
and body specific to the command type.
Implement a command pool to allocate all necessary memory in a single
DMA allocation to reduce pressure on the TLB, and provide convenient
re-usable command objects for the entities to utilise.
Signed-off-by: Kieran Bingham
---
v2:
- Fix spelling typo in commit message
- constify, and staticify the instantiation of vsp1_extended_commands
- s/autfld_cmds/autofld_cmds/
- staticify cmd pool functions (Thanks kbuild-bot)
drivers/media/platform/vsp1/vsp1_dl.c | 190 +++-
drivers/media/platform/vsp1/vsp1_dl.h | 3 +-
2 files changed, 193 insertions(+)
diff --git a/drivers/media/platform/vsp1/vsp1_dl.c
b/drivers/media/platform/vsp1/vsp1_dl.c
index cd91b50deed1..d8392bd866f1 100644
--- a/drivers/media/platform/vsp1/vsp1_dl.c
+++ b/drivers/media/platform/vsp1/vsp1_dl.c
@@ -121,6 +121,30 @@ struct vsp1_dl_body_pool {
};
/**
+ * struct vsp1_cmd_pool - display list body pool
+ * @dma: DMA address of the entries
+ * @size: size of the full DMA memory pool in bytes
+ * @mem: CPU memory pointer for the pool
+ * @bodies: Array of DLB structures for the pool
+ * @free: List of free DLB entries
+ * @lock: Protects the pool and free list
+ * @vsp1: the VSP1 device
+ */
+struct vsp1_dl_cmd_pool {
+ /* DMA allocation */
+ dma_addr_t dma;
+ size_t size;
+ void *mem;
+
+ struct vsp1_dl_ext_cmd *cmds;
+ struct list_head free;
+
+ spinlock_t lock;
+
+ struct vsp1_device *vsp1;
+};
+
+/**
* struct vsp1_dl_list - Display list
* @list: entry in the display list manager lists
* @dlm: the display list manager
@@ -163,6 +187,7 @@ struct vsp1_dl_list {
* @queued: list queued to the hardware (written to the DL registers)
* @pending: list waiting to be queued to the hardware
* @pool: body pool for the display list bodies
+ * @autofld_cmds: command pool to support auto-fld interlaced mode
*/
struct vsp1_dl_manager {
unsigned int index;
@@ -176,6 +201,7 @@ struct vsp1_dl_manager {
struct vsp1_dl_list *pending;
struct vsp1_dl_body_pool *pool;
+ struct vsp1_dl_cmd_pool *autofld_cmds;
};
/*
-
@@ -339,6 +365,139 @@ void vsp1_dl_body_write(struct vsp1_dl_body *dlb, u32
reg, u32 data)
}
/*
-
+ * Display List Extended Command Management
+ */
+
+enum vsp1_extcmd_type {
+ VSP1_EXTCMD_AUTODISP,
+ VSP1_EXTCMD_AUTOFLD,
+};
+
+struct vsp1_extended_command_info {
+ u16 opcode;
+ size_t body_size;
+} static const vsp1_extended_commands[] = {
+ [VSP1_EXTCMD_AUTODISP] = { 0x02, 96 },
+ [VSP1_EXTCMD_AUTOFLD] = { 0x03, 160 },
+};
+
+/**
+ * vsp1_dl_cmd_pool_create - Create a pool of commands from a single allocation
+ * @vsp1: The VSP1 device
+ * @type: The command pool type
+ * @num_commands: The quantity of commands to allocate
+ *
+ * Allocate a pool of commands each with enough memory to contain the private
+ * data of each command. The allocation sizes are dependent upon the command
+ * type.
+ *
+ * Return a pointer to a pool on success or NULL if memory can't be allocated.
+ */
+static struct vsp1_dl_cmd_pool *
+vsp1_dl_cmd_pool_create(struct vsp1_device *vsp1, enum vsp1_extcmd_type type,
+ unsigned int num_cmds)
+{
+ struct vsp1_dl_cmd_pool *pool;
+ unsigned int i;
+ size_t cmd_size;
+
+ pool = kzalloc(sizeof(*pool), GFP_KERNEL);
+ if (!pool)
+ return NULL;
+
+ pool->cmds = kcalloc(num_cmds, sizeof(*pool->cmds), GFP_KERNEL);
+ if (!pool->cmds) {
+ kfree(pool);
+ return NULL;
+ }
+
+ cmd_size = sizeof(struct vsp1_dl_ext_cmd_header) +
+ vsp1_extended_commands[type].body_size;
+ cmd_size = ALIGN(cmd_size, 16);
+
+ pool->size = cmd_size * num_cmds;
+ pool->mem = dma_alloc_wc(vsp1->bus_master, pool->size, &pool->dma,
+GFP_KERNEL);
+ if (!pool->mem) {
+ kfree(pool->cmds);
+ kfree(pool);
+ return NULL;
+ }
+
+ spin_lock_init(&pool->lock);
+ INIT_LIST_HEAD(&pool->free);
+
+ for (i = 0; i < num_cmds; ++i) {
+ struct vsp1_dl_ext_cmd *cmd = &pool->cmds[i];
+ size_t cmd_offset = i * cmd_size;
+ size_t data_offset = sizeof(struct vsp1_dl_ext_cmd_header) +
+cmd_offset;
+
+ cmd->pool = pool;
+ cmd->cmd_opcode = vsp1_extended_commands[type].opcode;
+
+ /* TODO: Auto-disp can utilise more than one command per cmd */
+ cmd->num_cmds = 1;
[Bug 102646] [dc] Screen flickering under amdgpu-experimental [buggy auto power profile]
https://bugs.freedesktop.org/show_bug.cgi?id=102646 --- Comment #26 from Harry Wentland --- That regression commit is the one that introduced the new DC display driver, so going back to the last working commit will effectively be the same as disabling DC for you. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 05/11] media: vsp1: Clean up DLM objects on error
If there is an error allocating a display list within a DLM object
the existing display lists are not free'd, and neither is the DL body
pool.
Use the existing vsp1_dlm_destroy() function to clean up on error.
Signed-off-by: Kieran Bingham
---
drivers/media/platform/vsp1/vsp1_dl.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/vsp1/vsp1_dl.c
b/drivers/media/platform/vsp1/vsp1_dl.c
index 310ce81cd724..680eedb6fc9f 100644
--- a/drivers/media/platform/vsp1/vsp1_dl.c
+++ b/drivers/media/platform/vsp1/vsp1_dl.c
@@ -831,8 +831,10 @@ struct vsp1_dl_manager *vsp1_dlm_create(struct vsp1_device
*vsp1,
struct vsp1_dl_list *dl;
dl = vsp1_dl_list_alloc(dlm, dlm->pool);
- if (!dl)
+ if (!dl) {
+ vsp1_dlm_destroy(dlm);
return NULL;
+ }
list_add_tail(&dl->list, &dlm->free);
}
--
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 08/11] media: vsp1: Add support for extended display list headers
Extended display list headers allow pre and post command lists to be
executed by the VSP pipeline. This provides the base support for
features such as AUTO_FLD (for interlaced support) and AUTO_DISP (for
supporting continuous camera preview pipelines.
Signed-off-by: Kieran Bingham
---
v2:
- remove __packed attributes
drivers/media/platform/vsp1/vsp1.h | 1 +-
drivers/media/platform/vsp1/vsp1_dl.c | 83 +-
drivers/media/platform/vsp1/vsp1_dl.h | 29 -
drivers/media/platform/vsp1/vsp1_drv.c | 7 +-
drivers/media/platform/vsp1/vsp1_regs.h | 5 +-
5 files changed, 116 insertions(+), 9 deletions(-)
diff --git a/drivers/media/platform/vsp1/vsp1.h
b/drivers/media/platform/vsp1/vsp1.h
index 1c080538c993..bb3b32795206 100644
--- a/drivers/media/platform/vsp1/vsp1.h
+++ b/drivers/media/platform/vsp1/vsp1.h
@@ -55,6 +55,7 @@ struct vsp1_uds;
#define VSP1_HAS_HGO (1 << 7)
#define VSP1_HAS_HGT (1 << 8)
#define VSP1_HAS_BRS (1 << 9)
+#define VSP1_HAS_EXT_DL(1 << 10)
struct vsp1_device_info {
u32 version;
diff --git a/drivers/media/platform/vsp1/vsp1_dl.c
b/drivers/media/platform/vsp1/vsp1_dl.c
index 5f5706f8a84c..cd91b50deed1 100644
--- a/drivers/media/platform/vsp1/vsp1_dl.c
+++ b/drivers/media/platform/vsp1/vsp1_dl.c
@@ -26,6 +26,9 @@
#define VSP1_DLH_INT_ENABLE(1 << 1)
#define VSP1_DLH_AUTO_START(1 << 0)
+#define VSP1_DLH_EXT_PRE_CMD_EXEC (1 << 9)
+#define VSP1_DLH_EXT_POST_CMD_EXEC (1 << 8)
+
struct vsp1_dl_header_list {
u32 num_bytes;
u32 addr;
@@ -38,11 +41,34 @@ struct vsp1_dl_header {
u32 flags;
};
+struct vsp1_dl_ext_header {
+ u32 reserved0; /* alignment padding */
+
+ u16 pre_ext_cmd_qty;
+ u16 flags;
+ u32 pre_ext_cmd_plist;
+
+ u32 post_ext_cmd_qty;
+ u32 post_ext_cmd_plist;
+};
+
+struct vsp1_dl_header_extended {
+ struct vsp1_dl_header header;
+ struct vsp1_dl_ext_header ext;
+};
+
struct vsp1_dl_entry {
u32 addr;
u32 data;
};
+struct vsp1_dl_ext_cmd_header {
+ u32 cmd;
+ u32 flags;
+ u32 data;
+ u32 reserved;
+};
+
/**
* struct vsp1_dl_body - Display list body
* @list: entry in the display list list of bodies
@@ -99,9 +125,12 @@ struct vsp1_dl_body_pool {
* @list: entry in the display list manager lists
* @dlm: the display list manager
* @header: display list header
+ * @extended: extended display list header. NULL for normal lists
* @dma: DMA address for the header
* @body0: first display list body
* @bodies: list of extra display list bodies
+ * @pre_cmd: pre cmd to be issued through extended dl header
+ * @post_cmd: post cmd to be issued through extended dl header
* @has_chain: if true, indicates that there's a partition chain
* @chain: entry in the display list partition chain
*/
@@ -110,11 +139,15 @@ struct vsp1_dl_list {
struct vsp1_dl_manager *dlm;
struct vsp1_dl_header *header;
+ struct vsp1_dl_ext_header *extended;
dma_addr_t dma;
struct vsp1_dl_body *body0;
struct list_head bodies;
+ struct vsp1_dl_ext_cmd *pre_cmd;
+ struct vsp1_dl_ext_cmd *post_cmd;
+
bool has_chain;
struct list_head chain;
};
@@ -498,6 +531,14 @@ int vsp1_dl_list_add_chain(struct vsp1_dl_list *head,
return 0;
}
+static void vsp1_dl_ext_cmd_fill_header(struct vsp1_dl_ext_cmd *cmd)
+{
+ cmd->cmds[0].cmd = cmd->cmd_opcode;
+ cmd->cmds[0].flags = cmd->flags;
+ cmd->cmds[0].data = cmd->data_dma;
+ cmd->cmds[0].reserved = 0;
+}
+
static void vsp1_dl_list_fill_header(struct vsp1_dl_list *dl, bool is_last)
{
struct vsp1_dl_manager *dlm = dl->dlm;
@@ -550,6 +591,27 @@ static void vsp1_dl_list_fill_header(struct vsp1_dl_list
*dl, bool is_last)
*/
dl->header->flags = VSP1_DLH_INT_ENABLE;
}
+
+ if (!dl->extended)
+ return;
+
+ dl->extended->flags = 0;
+
+ if (dl->pre_cmd) {
+ dl->extended->pre_ext_cmd_plist = dl->pre_cmd->cmd_dma;
+ dl->extended->pre_ext_cmd_qty = dl->pre_cmd->num_cmds;
+ dl->extended->flags |= VSP1_DLH_EXT_PRE_CMD_EXEC;
+
+ vsp1_dl_ext_cmd_fill_header(dl->pre_cmd);
+ }
+
+ if (dl->post_cmd) {
+ dl->extended->pre_ext_cmd_plist = dl->post_cmd->cmd_dma;
+ dl->extended->pre_ext_cmd_qty = dl->post_cmd->num_cmds;
+ dl->extended->flags |= VSP1_DLH_EXT_POST_CMD_EXEC;
+
+ vsp1_dl_ext_cmd_fill_header(dl->pre_cmd);
+ }
}
static bool vsp1_dl_list_hw_update_pending(struct vsp1_dl_manager *dlm)
@@ -715,14 +777,20 @@ bool vsp1_dlm_irq_frame_end(struct vsp1_dl_manager *dlm)
}
/* Hardware Setup */
-void vsp1_dlm_setup(struct vsp1_device *vsp1)
+void vsp1_dlm_setup(struct vsp1_device *vsp1, unsigned int ind
[PATCH v2 03/11] media: vsp1: Rename dl_child to dl_next
Both vsp1_dl_list_commit() and __vsp1_dl_list_put() walk the display
list chain referencing the nodes as children, when in reality they are
siblings.
Update the terminology to 'dl_next' to be consistent with the
vsp1_video_pipeline_run() usage.
Signed-off-by: Kieran Bingham
---
drivers/media/platform/vsp1/vsp1_dl.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/media/platform/vsp1/vsp1_dl.c
b/drivers/media/platform/vsp1/vsp1_dl.c
index 85795b55a357..8162f4ce66eb 100644
--- a/drivers/media/platform/vsp1/vsp1_dl.c
+++ b/drivers/media/platform/vsp1/vsp1_dl.c
@@ -400,7 +400,7 @@ struct vsp1_dl_list *vsp1_dl_list_get(struct
vsp1_dl_manager *dlm)
/* This function must be called with the display list manager lock held.*/
static void __vsp1_dl_list_put(struct vsp1_dl_list *dl)
{
- struct vsp1_dl_list *dl_child;
+ struct vsp1_dl_list *dl_next;
if (!dl)
return;
@@ -410,8 +410,8 @@ static void __vsp1_dl_list_put(struct vsp1_dl_list *dl)
* hardware operation.
*/
if (dl->has_chain) {
- list_for_each_entry(dl_child, &dl->chain, chain)
- __vsp1_dl_list_put(dl_child);
+ list_for_each_entry(dl_next, &dl->chain, chain)
+ __vsp1_dl_list_put(dl_next);
}
dl->has_chain = false;
@@ -667,17 +667,17 @@ static void vsp1_dl_list_commit_singleshot(struct
vsp1_dl_list *dl)
void vsp1_dl_list_commit(struct vsp1_dl_list *dl)
{
struct vsp1_dl_manager *dlm = dl->dlm;
- struct vsp1_dl_list *dl_child;
+ struct vsp1_dl_list *dl_next;
unsigned long flags;
if (dlm->mode == VSP1_DL_MODE_HEADER) {
/* Fill the header for the head and chained display lists. */
vsp1_dl_list_fill_header(dl, list_empty(&dl->chain));
- list_for_each_entry(dl_child, &dl->chain, chain) {
- bool last = list_is_last(&dl_child->chain, &dl->chain);
+ list_for_each_entry(dl_next, &dl->chain, chain) {
+ bool last = list_is_last(&dl_next->chain, &dl->chain);
- vsp1_dl_list_fill_header(dl_child, last);
+ vsp1_dl_list_fill_header(dl_next, last);
}
}
--
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 01/11] media: vsp1: drm: Fix minor grammar error
The pixel format is 'unsupported'. Fix the small debug message which
incorrectly declares this.
Signed-off-by: Kieran Bingham
---
drivers/media/platform/vsp1/vsp1_drm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/platform/vsp1/vsp1_drm.c
b/drivers/media/platform/vsp1/vsp1_drm.c
index 3c8b1952799d..0459b970e9da 100644
--- a/drivers/media/platform/vsp1/vsp1_drm.c
+++ b/drivers/media/platform/vsp1/vsp1_drm.c
@@ -363,7 +363,7 @@ int vsp1_du_atomic_update(struct device *dev, unsigned int
pipe_index,
*/
fmtinfo = vsp1_get_format_info(vsp1, cfg->pixelformat);
if (!fmtinfo) {
- dev_dbg(vsp1->dev, "Unsupport pixel format %08x for RPF\n",
+ dev_dbg(vsp1->dev, "Unsupported pixel format %08x for RPF\n",
cfg->pixelformat);
return -EINVAL;
}
--
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 06/11] media: vsp1: Provide VSP1 feature helper macro
The VSP1 devices define their specific capabilities through features
marked in their device info structure. Various parts of the code read
this info structure to infer if the features are available.
Wrap this into a more readable vsp1_feature(vsp1, f) macro to ensure
that usage is consistent throughout the driver.
Signed-off-by: Kieran Bingham
---
drivers/media/platform/vsp1/vsp1.h | 2 ++
drivers/media/platform/vsp1/vsp1_drv.c | 16
drivers/media/platform/vsp1/vsp1_wpf.c | 6 +++---
3 files changed, 13 insertions(+), 11 deletions(-)
diff --git a/drivers/media/platform/vsp1/vsp1.h
b/drivers/media/platform/vsp1/vsp1.h
index 78ef838416b3..1c080538c993 100644
--- a/drivers/media/platform/vsp1/vsp1.h
+++ b/drivers/media/platform/vsp1/vsp1.h
@@ -69,6 +69,8 @@ struct vsp1_device_info {
bool uapi;
};
+#define vsp1_feature(vsp1, f) ((vsp1)->info->features & (f))
+
struct vsp1_device {
struct device *dev;
const struct vsp1_device_info *info;
diff --git a/drivers/media/platform/vsp1/vsp1_drv.c
b/drivers/media/platform/vsp1/vsp1_drv.c
index eed9516e25e1..6fa0019ffc6e 100644
--- a/drivers/media/platform/vsp1/vsp1_drv.c
+++ b/drivers/media/platform/vsp1/vsp1_drv.c
@@ -268,7 +268,7 @@ static int vsp1_create_entities(struct vsp1_device *vsp1)
}
/* Instantiate all the entities. */
- if (vsp1->info->features & VSP1_HAS_BRS) {
+ if (vsp1_feature(vsp1, VSP1_HAS_BRS)) {
vsp1->brs = vsp1_bru_create(vsp1, VSP1_ENTITY_BRS);
if (IS_ERR(vsp1->brs)) {
ret = PTR_ERR(vsp1->brs);
@@ -278,7 +278,7 @@ static int vsp1_create_entities(struct vsp1_device *vsp1)
list_add_tail(&vsp1->brs->entity.list_dev, &vsp1->entities);
}
- if (vsp1->info->features & VSP1_HAS_BRU) {
+ if (vsp1_feature(vsp1, VSP1_HAS_BRU)) {
vsp1->bru = vsp1_bru_create(vsp1, VSP1_ENTITY_BRU);
if (IS_ERR(vsp1->bru)) {
ret = PTR_ERR(vsp1->bru);
@@ -288,7 +288,7 @@ static int vsp1_create_entities(struct vsp1_device *vsp1)
list_add_tail(&vsp1->bru->entity.list_dev, &vsp1->entities);
}
- if (vsp1->info->features & VSP1_HAS_CLU) {
+ if (vsp1_feature(vsp1, VSP1_HAS_CLU)) {
vsp1->clu = vsp1_clu_create(vsp1);
if (IS_ERR(vsp1->clu)) {
ret = PTR_ERR(vsp1->clu);
@@ -314,7 +314,7 @@ static int vsp1_create_entities(struct vsp1_device *vsp1)
list_add_tail(&vsp1->hst->entity.list_dev, &vsp1->entities);
- if (vsp1->info->features & VSP1_HAS_HGO && vsp1->info->uapi) {
+ if (vsp1_feature(vsp1, VSP1_HAS_HGO) && vsp1->info->uapi) {
vsp1->hgo = vsp1_hgo_create(vsp1);
if (IS_ERR(vsp1->hgo)) {
ret = PTR_ERR(vsp1->hgo);
@@ -325,7 +325,7 @@ static int vsp1_create_entities(struct vsp1_device *vsp1)
&vsp1->entities);
}
- if (vsp1->info->features & VSP1_HAS_HGT && vsp1->info->uapi) {
+ if (vsp1_feature(vsp1, VSP1_HAS_HGT) && vsp1->info->uapi) {
vsp1->hgt = vsp1_hgt_create(vsp1);
if (IS_ERR(vsp1->hgt)) {
ret = PTR_ERR(vsp1->hgt);
@@ -356,7 +356,7 @@ static int vsp1_create_entities(struct vsp1_device *vsp1)
}
}
- if (vsp1->info->features & VSP1_HAS_LUT) {
+ if (vsp1_feature(vsp1, VSP1_HAS_LUT)) {
vsp1->lut = vsp1_lut_create(vsp1);
if (IS_ERR(vsp1->lut)) {
ret = PTR_ERR(vsp1->lut);
@@ -390,7 +390,7 @@ static int vsp1_create_entities(struct vsp1_device *vsp1)
}
}
- if (vsp1->info->features & VSP1_HAS_SRU) {
+ if (vsp1_feature(vsp1, VSP1_HAS_SRU)) {
vsp1->sru = vsp1_sru_create(vsp1);
if (IS_ERR(vsp1->sru)) {
ret = PTR_ERR(vsp1->sru);
@@ -524,7 +524,7 @@ static int vsp1_device_init(struct vsp1_device *vsp1)
vsp1_write(vsp1, VI6_DPR_HSI_ROUTE, VI6_DPR_NODE_UNUSED);
vsp1_write(vsp1, VI6_DPR_BRU_ROUTE, VI6_DPR_NODE_UNUSED);
- if (vsp1->info->features & VSP1_HAS_BRS)
+ if (vsp1_feature(vsp1, VSP1_HAS_BRS))
vsp1_write(vsp1, VI6_DPR_ILV_BRS_ROUTE, VI6_DPR_NODE_UNUSED);
vsp1_write(vsp1, VI6_DPR_HGO_SMPPT, (7 << VI6_DPR_SMPPT_TGW_SHIFT) |
diff --git a/drivers/media/platform/vsp1/vsp1_wpf.c
b/drivers/media/platform/vsp1/vsp1_wpf.c
index 68218625549e..f90e474cf2cc 100644
--- a/drivers/media/platform/vsp1/vsp1_wpf.c
+++ b/drivers/media/platform/vsp1/vsp1_wpf.c
@@ -146,13 +146,13 @@ static int wpf_init_controls(struct vsp1_rwpf *wpf)
if (wpf->entity.index != 0) {
/* Only WPF0 supports flipping. */
num_flip_ctrls = 0;
- } else if (vsp1->info->features & VSP1_HAS_WPF_HFLIP) {
+ } else if (vsp1_feature(vsp1, VSP1_HAS_WPF
[PATCH v2 04/11] media: vsp1: Remove unused display list structure field
The vsp1 reference in the vsp1_dl_body structure is not used.
Remove it.
Signed-off-by: Kieran Bingham
---
drivers/media/platform/vsp1/vsp1_dl.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/media/platform/vsp1/vsp1_dl.c
b/drivers/media/platform/vsp1/vsp1_dl.c
index 8162f4ce66eb..310ce81cd724 100644
--- a/drivers/media/platform/vsp1/vsp1_dl.c
+++ b/drivers/media/platform/vsp1/vsp1_dl.c
@@ -48,7 +48,6 @@ struct vsp1_dl_entry {
* @list: entry in the display list list of bodies
* @free: entry in the pool free body list
* @pool: pool to which this body belongs
- * @vsp1: the VSP1 device
* @entries: array of entries
* @dma: DMA address of the entries
* @size: size of the DMA memory in bytes
@@ -62,7 +61,6 @@ struct vsp1_dl_body {
refcount_t refcnt;
struct vsp1_dl_body_pool *pool;
- struct vsp1_device *vsp1;
struct vsp1_dl_entry *entries;
dma_addr_t dma;
--
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 00/11] R-Car DU Interlaced support through VSP1
The Gen3 R-Car DU devices make use of the VSP to handle frame processing. In this series we implement support for handling interlaced pipelines by using the auto-fld feature of the VSP hardware. The implementation is preceded by some cleanup work and refactoring, through patches 1 to 6. These are trivial and could be collected earlier and independently if this series requires further revisions. Patch 7 makes a key distinctive change to remove all existing support for headerless display lists throughout the VSP1 driver, and ensures that all pipelines use the same code path. This simplifies the code and reduces opportunity for untested code paths to exist. Patches 8, 9 and 10 implement the relevant support in the VSP1 driver, before patch 11 finally enables the feature through the drm R-Car DU driver. This series is based upon my previous TLB optimise and body rework (v7), and is available from the following URL: git://git.kernel.org/pub/scm/linux/kernel/git/kbingham/rcar.git tags/vsp1/du/interlaced/v2 ChangeLog: v2: - media: vsp1: use kernel __packed for structures became: media: vsp1: Remove packed attributes from aligned structures - media: vsp1: Add support for extended display list headers - No longer declares structs __packed - media: vsp1: Provide support for extended command pools - Fix spelling typo in commit message - constify, and staticify the instantiation of vsp1_extended_commands - s/autfld_cmds/autofld_cmds/ - staticify cmd pool functions (Thanks kbuild-bot) - media: vsp1: Support Interlaced display pipelines - fix erroneous BIT value which enabled interlaced - fix field handling at frame_end interrupt Kieran Bingham (11): media: vsp1: drm: Fix minor grammar error media: vsp1: Remove packed attributes from aligned structures media: vsp1: Rename dl_child to dl_next media: vsp1: Remove unused display list structure field media: vsp1: Clean up DLM objects on error media: vsp1: Provide VSP1 feature helper macro media: vsp1: Use header display lists for all WPF outputs linked to the DU media: vsp1: Add support for extended display list headers media: vsp1: Provide support for extended command pools media: vsp1: Support Interlaced display pipelines drm: rcar-du: Support interlaced video output through vsp1 drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 1 +- drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 3 +- drivers/media/platform/vsp1/vsp1.h | 3 +- drivers/media/platform/vsp1/vsp1_dl.c | 406 +++-- drivers/media/platform/vsp1/vsp1_dl.h | 32 +- drivers/media/platform/vsp1/vsp1_drm.c | 13 +- drivers/media/platform/vsp1/vsp1_drv.c | 23 +- drivers/media/platform/vsp1/vsp1_regs.h | 6 +- drivers/media/platform/vsp1/vsp1_rpf.c | 72 +++- drivers/media/platform/vsp1/vsp1_rwpf.h | 1 +- drivers/media/platform/vsp1/vsp1_wpf.c | 6 +- include/media/vsp1.h| 1 +- 12 files changed, 455 insertions(+), 112 deletions(-) base-commit: 397eb3811ec096d0ceefa1dbea2d0ae68feb0587 -- git-series 0.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 02/11] media: vsp1: Remove packed attributes from aligned structures
The use of the packed attribute can cause a performance penalty for
all accesses to the struct members, as the compiler will assume that the
structure has the potential to have an unaligned base.
These structures are all correctly aligned and contain no holes, thus
the attribute is redundant and negatively impacts performance, so we
remove the attributes entirely.
Signed-off-by: Kieran Bingham
---
v2
- Remove attributes entirely
drivers/media/platform/vsp1/vsp1_dl.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/media/platform/vsp1/vsp1_dl.c
b/drivers/media/platform/vsp1/vsp1_dl.c
index 37e2c984fbf3..85795b55a357 100644
--- a/drivers/media/platform/vsp1/vsp1_dl.c
+++ b/drivers/media/platform/vsp1/vsp1_dl.c
@@ -29,19 +29,19 @@
struct vsp1_dl_header_list {
u32 num_bytes;
u32 addr;
-} __attribute__((__packed__));
+};
struct vsp1_dl_header {
u32 num_lists;
struct vsp1_dl_header_list lists[8];
u32 next_header;
u32 flags;
-} __attribute__((__packed__));
+};
struct vsp1_dl_entry {
u32 addr;
u32 data;
-} __attribute__((__packed__));
+};
/**
* struct vsp1_dl_body - Display list body
--
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/sun4i: Handle DRM_BUS_FLAG_PIXDATA_*EDGE
Handle both positive and negative dclk polarity,
according to bus_flags, taking care of this:
On A20 and similar SoCs, the only way to achieve Positive Edge
(Rising Edge), is setting dclk clock phase to 2/3(240°).
By default TCON works in Negative Edge(Falling Edge), this is why phase
is set to 0 in that case.
Unfortunately there's no way to logically invert dclk through IO_POL
register.
The only acceptable way to work, triple checked with scope,
is using clock phase set to 0° for Negative Edge and set to 240° for
Positive Edge.
On A33 and similar SoCs there would be a 90° phase option, but it divides
also dclk by 2.
This patch is a way to avoid quirks all around TCON and DOTCLOCK drivers
for using A33 90° phase divided by 2 and consequently increase code
complexity.
Signed-off-by: Giulio Benetti
---
drivers/gpu/drm/sun4i/sun4i_tcon.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index 8ee87c2..3f1455d 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include
@@ -345,6 +346,9 @@ static void sun4i_tcon0_mode_set_lvds(struct sun4i_tcon
*tcon,
static void sun4i_tcon0_mode_set_rgb(struct sun4i_tcon *tcon,
const struct drm_display_mode *mode)
{
+ struct drm_panel *panel = tcon->panel;
+ struct drm_connector *connector = panel->connector;
+ struct drm_display_info display_info = connector->display_info;
unsigned int bp, hsync, vsync;
u8 clk_delay;
u32 val = 0;
@@ -400,6 +404,27 @@ static void sun4i_tcon0_mode_set_rgb(struct sun4i_tcon
*tcon,
if (mode->flags & DRM_MODE_FLAG_PVSYNC)
val |= SUN4I_TCON0_IO_POL_VSYNC_POSITIVE;
+ /*
+* On A20 and similar SoCs, the only way to achieve Positive Edge
+* (Rising Edge), is setting dclk clock phase to 2/3(240°).
+* By default TCON works in Negative Edge(Falling Edge),
+* this is why phase is set to 0 in that case.
+* Unfortunately there's no way to logically invert dclk through
+* IO_POL register.
+* The only acceptable way to work, triple checked with scope,
+* is using clock phase set to 0° for Negative Edge and set to 240°
+* for Positive Edge.
+* On A33 and similar SoCs there would be a 90° phase option,
+* but it divides also dclk by 2.
+* Following code is a way to avoid quirks all around TCON
+* and DOTCLOCK drivers.
+*/
+ if (display_info.bus_flags & DRM_BUS_FLAG_PIXDATA_POSEDGE)
+ clk_set_phase(tcon->dclk, 240);
+
+ if (display_info.bus_flags & DRM_BUS_FLAG_PIXDATA_NEGEDGE)
+ clk_set_phase(tcon->dclk, 0);
+
regmap_update_bits(tcon->regs, SUN4I_TCON0_IO_POL_REG,
SUN4I_TCON0_IO_POL_HSYNC_POSITIVE |
SUN4I_TCON0_IO_POL_VSYNC_POSITIVE,
val);
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] [v2] drm/i915/pmu: avoid -Wmaybe-uninitialized warning
On 13/03/2018 16:19, Arnd Bergmann wrote:
The conditional spinlock confuses gcc into thinking the 'flags' value
might contain uninitialized data:
drivers/gpu/drm/i915/i915_pmu.c: In function '__i915_pmu_event_read':
arch/x86/include/asm/paravirt_types.h:573:3: error: 'flags' may be used
uninitialized in this function [-Werror=maybe-uninitialized]
Hm, how does paravirt_types.h comes into the picture?
The code is correct, but it's easy to see how the compiler gets confused
here. This avoids the problem by pulling the lock outside of the function
into its only caller.
Is it specific gcc version, specific options, or specific kernel config
that this happens?
Strange that it hasn't been seen so far.
Regards,
Tvrtko
Fixes: 1fe699e30113 ("drm/i915/pmu: Fix sleep under atomic in RC6 readout")
Signed-off-by: Arnd Bergmann
---
v2: removed unused function argument, fixed 'break' statement.
---
drivers/gpu/drm/i915/i915_pmu.c | 25 ++---
1 file changed, 10 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index 4bc7aefa9541..d6b9b6b5fb98 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -412,10 +412,9 @@ static u64 __get_rc6(struct drm_i915_private *i915)
return val;
}
-static u64 get_rc6(struct drm_i915_private *i915, bool locked)
+static u64 get_rc6(struct drm_i915_private *i915)
{
#if IS_ENABLED(CONFIG_PM)
- unsigned long flags;
u64 val;
if (intel_runtime_pm_get_if_in_use(i915)) {
@@ -428,18 +427,12 @@ static u64 get_rc6(struct drm_i915_private *i915, bool
locked)
* previously.
*/
- if (!locked)
- spin_lock_irqsave(&i915->pmu.lock, flags);
-
if (val >= i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur) {
i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur = 0;
i915->pmu.sample[__I915_SAMPLE_RC6].cur = val;
} else {
val = i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur;
}
-
- if (!locked)
- spin_unlock_irqrestore(&i915->pmu.lock, flags);
} else {
struct pci_dev *pdev = i915->drm.pdev;
struct device *kdev = &pdev->dev;
@@ -452,9 +445,6 @@ static u64 get_rc6(struct drm_i915_private *i915, bool
locked)
* on top of the last known real value, as the approximated RC6
* counter value.
*/
- if (!locked)
- spin_lock_irqsave(&i915->pmu.lock, flags);
-
spin_lock_irqsave(&kdev->power.lock, flags2);
if (!i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur)
@@ -470,9 +460,6 @@ static u64 get_rc6(struct drm_i915_private *i915, bool
locked)
val = jiffies_to_nsecs(val);
val += i915->pmu.sample[__I915_SAMPLE_RC6].cur;
i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur = val;
-
- if (!locked)
- spin_unlock_irqrestore(&i915->pmu.lock, flags);
}
return val;
@@ -519,7 +506,15 @@ static u64 __i915_pmu_event_read(struct perf_event *event,
bool locked)
val = count_interrupts(i915);
break;
case I915_PMU_RC6_RESIDENCY:
- val = get_rc6(i915, locked);
+ if (!locked) {
+ unsigned long flags;
+
+ spin_lock_irqsave(&i915->pmu.lock, flags);
+ val = get_rc6(i915);
+ spin_unlock_irqrestore(&i915->pmu.lock, flags);
+ } else {
+ val = get_rc6(i915);
+ }
break;
}
}
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 104216] Firefox quirks (black and/or white squares)
https://bugs.freedesktop.org/show_bug.cgi?id=104216 --- Comment #22 from Germano Massullo --- (In reply to Michel Dänzer from comment #21) > (In reply to Germano Massullo from comment #20) > > I experienced the problem with both of them. > > Did you check in Firefox about:support (look for "Driver Version") that it > was actually using your self-built Mesa? > > > BTW, I notice a lot of messages like > > [GFX1-]: ClientLayerManager::BeginTransaction with IPC channel down. GPU > process may have died. > > in the Firefox output you attached. Have you contacted Firefox folks about > whether those are harmless, or how to get more information about them? You are right. There were a ton of such messages, plus other messages concerning load failures of radeonsi, and other libraries. about:support contained so many errors, that I was surprised I even had the opportunity to use Firefox for many days. Since the libraries were available in the LD_LIBRARY_PATH and LIBGL_DRIVERS_PATH, I tried to run $ LD_LIBRARY_PATH='foo/mesa_n_version/usr/lib64/' LIBGL_DRIVERS_PATH='foo/mesa_n_version/usr/lib64/dri' firefox instead of $ LD_LIBRARY_PATH='foo/mesa_n_version/usr/$LIB/' LIBGL_DRIVERS_PATH='foo/mesa_n_version/usr/$LIB/dri' firefox and I got no errors except for those few lines. (/usr/lib64/firefox/firefox:8582): dconf-WARNING **: Unable to open /var/lib/flatpak/exports/share/dconf/profile/user: Permission denied ATTENTION: default value of option force_s3tc_enable overridden by environment. WebGL(0x7f9488ce7800)::ForceLoseContext WebGL(0x7f945e1b8000)::ForceLoseContext [Child 8509, MediaPlayback #5] WARNING: Decoder=7fa5623cf400 state=DECODING_METADATA Decode metadata failed, shutting down decoder: file /builddir/build/BUILD/firefox-58.0.2/dom/media/MediaDecoderStateMachine.cpp, line 372 [Child 8509, MediaPlayback #5] WARNING: Decoder=7fa5623cf400 Decode error: NS_ERROR_DOM_MEDIA_METADATA_ERR (0x806e0006): file /builddir/build/BUILD/firefox-58.0.2/dom/media/MediaDecoderStateMachine.cpp, line 3365 about:support is fine too. I don't know why $LIB caused such problems to Firefox in Fedora 27. I am actually testing again both Mesa 17.0.5 and 18.0.0 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 0/7] Modernize vga_switcheroo by using device link for HDA
On Sun, Mar 11, 2018 at 04:55:49PM +0100, Lukas Wunner wrote: > On Tue, Mar 06, 2018 at 11:29:40AM +0100, Daniel Vetter wrote: > > On Sat, Mar 03, 2018 at 10:53:24AM +0100, Lukas Wunner wrote: > > > Modernize vga_switcheroo by using a device link to enforce a runtime PM > > > dependency from an HDA controller to the GPU it's integrated into, v2. > > > > > > https://github.com/l1k/linux/commits/switcheroo_devlink_v2 > > > > This all looks really reasonable and like a good cleanup, but it's a bit > > too much detail so I'll punt review to someone else with more clue. > > Patches [3/7] to [7/7] were reviewed by Peter Wu, the HDA bits in > patch [5/7] additionally by Takashi. > > Patch [2/7] was acked by Bjorn. There was no ack for patch [1/7] > (authored by Rafael), but it adressed the objection Bjorn raised > against my original patch, so I'm assuming Bjorn is okay with it. > (Bjorn, please let me know if that isn't the case.) I am OK with it. I sent an ack and possible minor changelog tweak. I expect that you'll merge the whole series via drm-misc. > The series has been tested on 5 systems, which raises the confidence: > 2x AMD PowerXpress (Mike Lothian, Kai Heng Feng) > 2x Nvidia Optimus (Denis Lisov, Peter Wu) > 1x MacBook Pro > > The issues found during Peter Wu's thorough testing appear to all > be unrelated to this series, as per my e-mail yesterday. > > If there are no objections, I plan to push the series to > drm-misc-next by the middle of the coming week so that it > would still catch the last train to 4.17. > > Thanks, > > Lukas ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/7] PCI: Restore config space on runtime resume despite being unbound
On Sat, Mar 03, 2018 at 10:53:24AM +0100, Lukas Wunner wrote:
> From: Rafael J. Wysocki
>
> We leave PCI devices not bound to a driver in D0 during runtime suspend.
> But they may have a parent which is bound and can be transitioned to
> D3cold at runtime. Once the parent goes to D3cold, the unbound child
> may go to D3cold as well. When the child comes out of D3cold, its BARs
> are uninitialized and thus inaccessible when a driver tries to probe.
There's no clear way to tell whether a BAR is uninitialized. At
power-up, the writable bits will be zero, which is a valid BAR value.
If enabled in PCI_COMMAND, the BAR is accessible and may conflict with
other devices.
Possible alternate wording:
When the child goes to D3cold, its internal state, including
configuration of BARs, MSI, ASPM, MPS, etc., is lost.
> Moreover configuration done during enumeration, e.g. ASPM and MPS, will
> be lost.
>
> One example are recent hybrid graphics laptops which cut power to the
> discrete GPU when the root port above it goes to ACPI power state D3.
> Users may provoke this by unbinding the GPU driver and allowing runtime
> PM on the GPU via sysfs: The PM core will then treat the GPU as
> "suspended", which in turn allows the root port to runtime suspend,
> causing the power resources listed in its _PR3 object to be powered off.
> The GPU's BARs will be uninitialized when a driver later probes it.
>
> Another example are hybrid graphics laptops where the GPU itself (rather
> than the root port) is capable of runtime suspending to D3cold. If the
> GPU's integrated HDA controller is not bound and the GPU's driver
> decides to runtime suspend to D3cold, the HDA controller's BARs will be
> uninitialized when a driver later probes it.
>
> Fix by saving and restoring config space over a runtime suspend cycle
> even if the device is not bound.
>
> Cc: Bjorn Helgaas
> Signed-off-by: Rafael J. Wysocki
> [lukas: add commit message, bikeshed code comments for clarity]
> Signed-off-by: Lukas Wunner
Acked-by: Bjorn Helgaas
> ---
> Changes since v1:
> - Replace patch to use pci_save_state() / pci_restore_state()
> for consistency between runtime PM code path of bound and unbound
> devices. (Rafael, Bjorn)
>
> drivers/pci/pci-driver.c | 17 +++--
> 1 file changed, 11 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c
> index 3bed6beda051..6a67cdbd0e6a 100644
> --- a/drivers/pci/pci-driver.c
> +++ b/drivers/pci/pci-driver.c
> @@ -1224,11 +1224,14 @@ static int pci_pm_runtime_suspend(struct device *dev)
> int error;
>
> /*
> - * If pci_dev->driver is not set (unbound), the device should
> - * always remain in D0 regardless of the runtime PM status
> + * If pci_dev->driver is not set (unbound), we leave the device in D0,
> + * but it may go to D3cold when the bridge above it runtime suspends.
> + * Save its config space in case that happens.
Thanks for this clarification.
>*/
> - if (!pci_dev->driver)
> + if (!pci_dev->driver) {
> + pci_save_state(pci_dev);
> return 0;
> + }
>
> if (!pm || !pm->runtime_suspend)
> return -ENOSYS;
> @@ -1276,16 +1279,18 @@ static int pci_pm_runtime_resume(struct device *dev)
> const struct dev_pm_ops *pm = dev->driver ? dev->driver->pm : NULL;
>
> /*
> - * If pci_dev->driver is not set (unbound), the device should
> - * always remain in D0 regardless of the runtime PM status
> + * Restoring config space is necessary even if the device is not bound
> + * to a driver because although we left it in D0, it may have gone to
> + * D3cold when the bridge above it runtime suspended.
>*/
> + pci_restore_standard_config(pci_dev);
> +
> if (!pci_dev->driver)
> return 0;
>
> if (!pm || !pm->runtime_resume)
> return -ENOSYS;
>
> - pci_restore_standard_config(pci_dev);
> pci_fixup_device(pci_fixup_resume_early, pci_dev);
> pci_enable_wake(pci_dev, PCI_D0, false);
> pci_fixup_device(pci_fixup_resume, pci_dev);
> --
> 2.15.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/4] dma-buf: add optional invalidate_mappings callback
Am 13.03.2018 um 17:00 schrieb Daniel Vetter: On Tue, Mar 13, 2018 at 04:52:02PM +0100, Christian König wrote: Am 13.03.2018 um 16:17 schrieb Daniel Vetter: [SNIP] Ok, so plan is to support fully pipeline moves and everything, with the old sg tables lazily cleaned up. I was thinking more about evicting stuff and throwing it out, where there's not going to be any new sg list but the object is going to be swapped out. Yes, exactly. Well my example was the unlikely case when the object is swapped out and immediately swapped in again because somebody needs it. I think some state flow charts (we can do SVG or DOT) in the kerneldoc would be sweet.Yeah, probably a good idea. Sounds good and I find it great that you're volunteering for that :D Ok seriously, my drawing capabilities are a bit underdeveloped. So I would prefer if somebody could at least help with that. Re GPU might cause a deadlock: Isn't that already a problem if you hold reservations of buffers used on other gpus, which want those reservations to complete the gpu reset, but that gpu reset blocks some fence that the reservation holder is waiting for? Correct, that's why amdgpu and TTM tries quite hard to never wait for a fence while a reservation object is locked. We might have a fairly huge mismatch of expectations here :-/ What do you mean with that? The only use case I haven't fixed so far is reaping deleted object during eviction, but that is only a matter of my free time to fix it. Yeah, this is the hard one. Actually it isn't so hard, it's just that I didn't had time so far to clean it up and we never hit that issue so far during our reset testing. The main point missing just a bit of functionality in the reservation object and Chris and I already had a good idea how to implement that. In general the assumption is that dma_fence will get signalled no matter what you're doing, assuming the only thing you need is to not block interrupts. The i915 gpu reset logic to make that work is a bit a work of art ... Correct, but I don't understand why that is so hard on i915? Our GPU scheduler makes all of that rather trivial, e.g. fences either signal correctly or are aborted and set as erroneous after a timeout. If we expect amdgpu and i915 to cooperate with shared buffers I guess one has to give in. No idea how to do that best. Again at least from amdgpu side I don't see much of an issue with that. So what exactly do you have in mind here? We have tons of fun with deadlocks against GPU resets, and loots of testcases, and I kinda get the impression amdgpu is throwing a lot of issues under the rug through trylock tricks that shut up lockdep, but don't fix much really. Hui? Why do you think that? The only trylock I'm aware of is during eviction and there it isn't a problem. mmap fault handler had one too last time I looked, and it smelled fishy. Good point, never wrapped my head fully around that one either. btw adding cross-release lockdep annotations for fences will probably turn up _lots_ more bugs in this area. At least for amdgpu that should be handled by now. You're sure? :-) Yes, except for fallback paths and bootup self tests we simply never wait for fences while holding locks. Trouble is that cross-release wasn't even ever enabled, much less anyone typed the dma_fence annotations. And just cross-release alone turned up _lost_ of deadlocks in i915 between fences, async workers (userptr, gpu reset) and core mm stuff. Yeah, we had lots of fun with the mm locks as well but as far as I know Felix and I already fixed all of them. Christian. I'd be seriously surprised if it wouldn't find an entire rats nest of issues around dma_fence once we enable it. -Daniel +* +* New mappings can be created immediately, but can't be used before the +* exclusive fence in the dma_bufs reservation object is signaled. +*/ + void (*invalidate_mappings)(struct dma_buf_attachment *attach); Bunch of questions about exact semantics, but I very much like this. And I think besides those technical details, the overall approach seems sound. Yeah this initial implementation was buggy like hell. Just wanted to confirm that the idea is going in the right direction. I wanted this 7 years ago, idea very much acked :-) Ok, thanks. Good to know. Christian. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] [v2] drm/i915/pmu: avoid -Wmaybe-uninitialized warning
Quoting Arnd Bergmann (2018-03-13 16:19:31)
> The conditional spinlock confuses gcc into thinking the 'flags' value
> might contain uninitialized data:
>
> drivers/gpu/drm/i915/i915_pmu.c: In function '__i915_pmu_event_read':
> arch/x86/include/asm/paravirt_types.h:573:3: error: 'flags' may be used
> uninitialized in this function [-Werror=maybe-uninitialized]
>
> The code is correct, but it's easy to see how the compiler gets confused
> here. This avoids the problem by pulling the lock outside of the function
> into its only caller.
>
> Fixes: 1fe699e30113 ("drm/i915/pmu: Fix sleep under atomic in RC6 readout")
> Signed-off-by: Arnd Bergmann
Reviewed-by: Chris Wilson
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 105436] Blinking textures in UT2004 [bisected]
https://bugs.freedesktop.org/show_bug.cgi?id=105436 almos changed: What|Removed |Added Assignee|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop. |.org|org Component|Drivers/Gallium/radeonsi|Mesa core QA Contact|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop. |.org|org Summary|Blinking textures in UT2004 |Blinking textures in UT2004 ||[bisected] --- Comment #2 from almos --- f314a532fdc7af8381586144d2631d9968331f05 is the first bad commit commit f314a532fdc7af8381586144d2631d9968331f05 Author: Samuel Pitoiset Date: Wed Jun 21 11:31:43 2017 +0200 mesa: do not trigger _NEW_TEXTURE_STATE in glActiveTexture() This looks like useless because gl_context::Texture::CurrentUnit is not used by _mesa_update_texture_state() and friends. Signed-off-by: Samuel Pitoiset Reviewed-by: Brian Paul :04 04 c2a46b6dcce50edf810147e07de977f38d33533a 606c977b6357381074d205daf2815ebb93da1029 M src Adding back the FLUSH_VERTICES fixes the issue. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 102646] [dc] Screen flickering under amdgpu-experimental [buggy auto power profile]
https://bugs.freedesktop.org/show_bug.cgi?id=102646 --- Comment #25 from Ruben Harutyunyan --- Seems like this is a regression actually. I've managed bisect the commit which caused the problems. Last working commit: https://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-next-4.15-dc&id=8ee5702afdd48b5864c46418ad310d6a23c8e9ab Breaking commit: https://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-next-4.15-dc&id=b9e56e41e0c55c2b2ab5919c5e167faa4200b083 Keep in mind that you need https://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-next-4.15-dc&id=9ba29fcb76a559078491adffc74f66bf92b9dbea commit to be able to compile the kernel, but judging by the changes the merge commit was the one that broke it. Some more details: 1) Disabling/enabling FreeSync doesn't matter 2) Issue happens under Xorg KDE/Wayland Gnome/Xorg GNOME 3) HDMI or DP doesn't matter I'd try to narrow it down to the exact part of the commit that causes the issue, but I am having an issue with my Ryzen soft locking thread by thread until a complete lockup happens when compiling with 16 threads. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] [v2] drm/i915/pmu: avoid -Wmaybe-uninitialized warning
The conditional spinlock confuses gcc into thinking the 'flags' value
might contain uninitialized data:
drivers/gpu/drm/i915/i915_pmu.c: In function '__i915_pmu_event_read':
arch/x86/include/asm/paravirt_types.h:573:3: error: 'flags' may be used
uninitialized in this function [-Werror=maybe-uninitialized]
The code is correct, but it's easy to see how the compiler gets confused
here. This avoids the problem by pulling the lock outside of the function
into its only caller.
Fixes: 1fe699e30113 ("drm/i915/pmu: Fix sleep under atomic in RC6 readout")
Signed-off-by: Arnd Bergmann
---
v2: removed unused function argument, fixed 'break' statement.
---
drivers/gpu/drm/i915/i915_pmu.c | 25 ++---
1 file changed, 10 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index 4bc7aefa9541..d6b9b6b5fb98 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -412,10 +412,9 @@ static u64 __get_rc6(struct drm_i915_private *i915)
return val;
}
-static u64 get_rc6(struct drm_i915_private *i915, bool locked)
+static u64 get_rc6(struct drm_i915_private *i915)
{
#if IS_ENABLED(CONFIG_PM)
- unsigned long flags;
u64 val;
if (intel_runtime_pm_get_if_in_use(i915)) {
@@ -428,18 +427,12 @@ static u64 get_rc6(struct drm_i915_private *i915, bool
locked)
* previously.
*/
- if (!locked)
- spin_lock_irqsave(&i915->pmu.lock, flags);
-
if (val >= i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur) {
i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur = 0;
i915->pmu.sample[__I915_SAMPLE_RC6].cur = val;
} else {
val = i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur;
}
-
- if (!locked)
- spin_unlock_irqrestore(&i915->pmu.lock, flags);
} else {
struct pci_dev *pdev = i915->drm.pdev;
struct device *kdev = &pdev->dev;
@@ -452,9 +445,6 @@ static u64 get_rc6(struct drm_i915_private *i915, bool
locked)
* on top of the last known real value, as the approximated RC6
* counter value.
*/
- if (!locked)
- spin_lock_irqsave(&i915->pmu.lock, flags);
-
spin_lock_irqsave(&kdev->power.lock, flags2);
if (!i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur)
@@ -470,9 +460,6 @@ static u64 get_rc6(struct drm_i915_private *i915, bool
locked)
val = jiffies_to_nsecs(val);
val += i915->pmu.sample[__I915_SAMPLE_RC6].cur;
i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur = val;
-
- if (!locked)
- spin_unlock_irqrestore(&i915->pmu.lock, flags);
}
return val;
@@ -519,7 +506,15 @@ static u64 __i915_pmu_event_read(struct perf_event *event,
bool locked)
val = count_interrupts(i915);
break;
case I915_PMU_RC6_RESIDENCY:
- val = get_rc6(i915, locked);
+ if (!locked) {
+ unsigned long flags;
+
+ spin_lock_irqsave(&i915->pmu.lock, flags);
+ val = get_rc6(i915);
+ spin_unlock_irqrestore(&i915->pmu.lock, flags);
+ } else {
+ val = get_rc6(i915);
+ }
break;
}
}
--
2.9.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH RESEND v2 1/2] drm/xen-front: Add support for Xen PV display frontend
From: Oleksandr Andrushchenko Add support for Xen para-virtualized frontend display driver. Accompanying backend [1] is implemented as a user-space application and its helper library [2], capable of running as a Weston client or DRM master. Configuration of both backend and frontend is done via Xen guest domain configuration options [3]. Driver limitations: 1. Only primary plane without additional properties is supported. 2. Only one video mode supported which resolution is configured via XenStore. 3. All CRTCs operate at fixed frequency of 60Hz. 1. Implement Xen bus state machine for the frontend driver according to the state diagram and recovery flow from display para-virtualized protocol: xen/interface/io/displif.h. 2. Read configuration values from Xen store according to xen/interface/io/displif.h protocol: - read connector(s) configuration - read buffer allocation mode (backend/frontend) 3. Handle Xen event channels: - create for all configured connectors and publish corresponding ring references and event channels in Xen store, so backend can connect - implement event channels interrupt handlers - create and destroy event channels with respect to Xen bus state 4. Implement shared buffer handling according to the para-virtualized display device protocol at xen/interface/io/displif.h: - handle page directories according to displif protocol: - allocate and share page directories - grant references to the required set of pages for the page directory - allocate xen balllooned pages via Xen balloon driver with alloc_xenballooned_pages/free_xenballooned_pages - grant references to the required set of pages for the shared buffer itself - implement pages map/unmap for the buffers allocated by the backend (gnttab_map_refs/gnttab_unmap_refs) 5. Implement kernel modesetiing/connector handling using DRM simple KMS helper pipeline: - implement KMS part of the driver with the help of DRM simple pipepline helper which is possible due to the fact that the para-virtualized driver only supports a single (primary) plane: - initialize connectors according to XenStore configuration - handle frame done events from the backend - create and destroy frame buffers and propagate those to the backend - propagate set/reset mode configuration to the backend on display enable/disable callbacks - send page flip request to the backend and implement logic for reporting backend IO errors on prepare fb callback - implement virtual connector handling: - support only pixel formats suitable for single plane modes - make sure the connector is always connected - support a single video mode as per para-virtualized driver configuration 6. Implement GEM handling depending on driver mode of operation: depending on the requirements for the para-virtualized environment, namely requirements dictated by the accompanying DRM/(v)GPU drivers running in both host and guest environments, number of operating modes of para-virtualized display driver are supported: - display buffers can be allocated by either frontend driver or backend - display buffers can be allocated to be contiguous in memory or not Note! Frontend driver itself has no dependency on contiguous memory for its operation. 6.1. Buffers allocated by the frontend driver. The below modes of operation are configured at compile-time via frontend driver's kernel configuration. 6.1.1. Front driver configured to use GEM CMA helpers This use-case is useful when used with accompanying DRM/vGPU driver in guest domain which was designed to only work with contiguous buffers, e.g. DRM driver based on GEM CMA helpers: such drivers can only import contiguous PRIME buffers, thus requiring frontend driver to provide such. In order to implement this mode of operation para-virtualized frontend driver can be configured to use GEM CMA helpers. 6.1.2. Front driver doesn't use GEM CMA If accompanying drivers can cope with non-contiguous memory then, to lower pressure on CMA subsystem of the kernel, driver can allocate buffers from system memory. Note! If used with accompanying DRM/(v)GPU drivers this mode of operation may require IOMMU support on the platform, so accompanying DRM/vGPU hardware can still reach display buffer memory while importing PRIME buffers from the frontend driver. 6.2. Buffers allocated by the backend This mode of operation is run-time configured via guest domain configuration through XenStore entries. For systems which do not provide IOMMU support, but having specific requirements for display buffers it is possible to allocate such buffers at backend side and share those with the frontend. For example, if host domain is 1:1 mapped and has DRM/GPU hardware expecting physically contiguous memory, this allows implementing zero-copying use-cases. Note, while using this scenario the following should be considered: a) If guest domain dies
[PATCH RESEND v2 0/2] drm/xen-front: Add support for Xen PV display frontend
From: Oleksandr Andrushchenko Hello! Resending with all the patches squashed on Daniel's request. This patch series adds support for Xen [1] para-virtualized frontend display driver. It implements the protocol from include/xen/interface/io/displif.h [2]. Accompanying backend [3] is implemented as a user-space application and its helper library [4], capable of running as a Weston client or DRM master. Configuration of both backend and frontend is done via Xen guest domain configuration options [5]. *** * Driver limitations *** 1. Configuration options 1.1 (contiguous display buffers) and 2 (backend allocated buffers) below are not supported at the same time. 2. Only primary plane without additional properties is supported. 3. Only one video mode supported which resolution is configured via XenStore. 4. All CRTCs operate at fixed frequency of 60Hz. *** * Driver modes of operation in terms of display buffers used *** Depending on the requirements for the para-virtualized environment, namely requirements dictated by the accompanying DRM/(v)GPU drivers running in both host and guest environments, number of operating modes of para-virtualized display driver are supported: - display buffers can be allocated by either frontend driver or backend - display buffers can be allocated to be contiguous in memory or not Note! Frontend driver itself has no dependency on contiguous memory for its operation. *** * 1. Buffers allocated by the frontend driver. *** The below modes of operation are configured at compile-time via frontend driver's kernel configuration. 1.1. Front driver configured to use GEM CMA helpers This use-case is useful when used with accompanying DRM/vGPU driver in guest domain which was designed to only work with contiguous buffers, e.g. DRM driver based on GEM CMA helpers: such drivers can only import contiguous PRIME buffers, thus requiring frontend driver to provide such. In order to implement this mode of operation para-virtualized frontend driver can be configured to use GEM CMA helpers. 1.2. Front driver doesn't use GEM CMA If accompanying drivers can cope with non-contiguous memory then, to lower pressure on CMA subsystem of the kernel, driver can allocate buffers from system memory. Note! If used with accompanying DRM/(v)GPU drivers this mode of operation may require IOMMU support on the platform, so accompanying DRM/vGPU hardware can still reach display buffer memory while importing PRIME buffers from the frontend driver. *** * 2. Buffers allocated by the backend *** This mode of operation is run-time configured via guest domain configuration through XenStore entries. For systems which do not provide IOMMU support, but having specific requirements for display buffers it is possible to allocate such buffers at backend side and share those with the frontend. For example, if host domain is 1:1 mapped and has DRM/GPU hardware expecting physically contiguous memory, this allows implementing zero-copying use-cases. I would like to thank at least, but not at last the following people/communities who helped this driver to happen ;) 1. My team at EPAM for continuous support 2. Xen community for answering tons of questions on different modes of operation of the driver with respect to virtualized environment. 3. Rob Clark for "GEM allocation for para-virtualized DRM driver" [6] 4. Maarten Lankhorst for "Atomic driver and old remove FB behavior" [7] 5. Ville Syrjälä for "Questions on page flips and atomic modeset" [8] Changes since v1: *** - use SPDX license identifier, set license to GPLv2 OR MIT - changed midlayers to direct function calls, removed: - front_ops - gem_ops - renamed xenbus_driver callbacks to align with exisitng PV drivers - re-worked backend error handling with connector hotplug uevents - removed vblank handling so user-space doesn't have an impression we really support that - directly use front's mode_set in display enable/disable - removed BUG_ON, error handling implemented - moved driver documentation into Documentation/gpu - other comments from Xen community addressed (Boris and Juergen) - squashed Xen and DRM patches for better interrconnection visibility - for your convenience driver i
[PATCH hwc v1] [RFC] drm_hwcomposer: Flatten composition using writeback connector
This patchset tries to add support for using writeback connector to
flatten a scene when it doesn't change for a while. This idea had
been floated around on IRC here [1] and here [2].
Developed on top of the latest writeback series, sent by Liviu here
[3].
Probably the patch should/could be broken in more patches, but since I
want to put this out there to get feedback, I kept them as a single
patch for now.
This change could be summarize as follow:
- Attach a writeback connector to the CRTC that's controlling a
display.
- Detect the scene did not change for a while(60 vblanks).
- Re-commit scene and get the composited scene through the writeback
connector.
- Commit the whole scene as a single plane.
Some areas that I consider important and I could use some
feedback/ideas:
1. Building the pipeline.
Currently, drm_hwcomposer allows to connect just a single connector
to a crtc. For now, I decided to treat the writeback connector as a
separate field inside DrmCrtc. I'm not sure if it's a good idea to try
to handle this in a unified way, since the writeback connector is such
a special connector. Regarding the allocation of writeback connectors,
my idea was to allocate writeback connector to the primary display
first and then continue allocating while respecting the display number. 0
gets a writeback before 1 and so on.
2. Heuristic for triggering the flattening.
I just created a VSyncWorker which will trigger the flattening of the
scene if it doesn't change for 60 consecutive vsyncs. The countdown
gets reset every time ValidateDisplay is called. This is a relatively
basic heuristic, so I'm open to suggestions.
3. Locking scheme corner cases.
The Vsynworker is a separate thread which will contend with
SurfaceFlinger for showing things on the screen. I tried to limit the
race window by resetting the countdown on ValidateDisplay and
explicitely checking that we still need to use the flatten scene before
commiting to get the writeback result or before applying the flattened
scene.
4. Building the DrmDisplayComposition for the flattened scene.
I kind of lost myself in all types of layers/planes and compositions,
so I'm not sure if I'm correctly building the DrmDisplayComposition
object for the FlattenScene, it works and shows what I expect on the
screen. So, any feedback here is appreciated.
5. I see there is a drmcompositorworker.cpp which implemented the same
idea using the GPU, however that seems to not be used anymore, does
anyone know the rationale behind it?
Some unfinished/untested things:
- Make sure the DrmFrameBuffer allocates one of the formats reported
in WRITEBACK_PIXEL_FORMATS.
- I'm using a hacked setup where, when needed it, the GL compositing is
done by Surfaceflinger, so I'm not sure how well this changes are
getting along with the GLCompositorWorker.
[1]
https://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel&highlight_names=&date=2018-02-23
[2]
https://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel&highlight_names=&date=2018-02-09
[3] https://lists.freedesktop.org/archives/dri-devel/2018-February/167703.html
Signed-off-by: Alexandru Gheorghe
---
drmconnector.cpp | 36 ++-
drmconnector.h | 8 +++
drmcrtc.cpp | 11 +++-
drmcrtc.h| 8 ++-
drmdisplaycompositor.cpp | 164 +--
drmdisplaycompositor.h | 16 +++--
drmencoder.cpp | 15 +
drmencoder.h | 7 +-
drmhwctwo.cpp| 1 +
drmresources.cpp | 56 +++-
drmresources.h | 1 +
11 files changed, 306 insertions(+), 17 deletions(-)
diff --git a/drmconnector.cpp b/drmconnector.cpp
index 145518f..2ed4f23 100644
--- a/drmconnector.cpp
+++ b/drmconnector.cpp
@@ -52,6 +52,23 @@ int DrmConnector::Init() {
ALOGE("Could not get CRTC_ID property\n");
return ret;
}
+ if (writeback()) {
+ret = drm_->GetConnectorProperty(*this, "WRITEBACK_PIXEL_FORMATS",
&writeback_pixel_formats_);
+if (ret) {
+ ALOGE("Could not get WRITEBACK_PIXEL_FORMATS connector_id = %d\n", id_);
+ return ret;
+}
+ret = drm_->GetConnectorProperty(*this, "WRITEBACK_FB_ID",
&writeback_fb_id_);
+if (ret) {
+ ALOGE("Could not get WRITEBACK_FB_ID connector_id = %d\n", id_);
+ return ret;
+}
+ret = drm_->GetConnectorProperty(*this, "WRITEBACK_OUT_FENCE_PTR",
&writeback_out_fence_);
+if (ret) {
+ ALOGE("Could not get WRITEBACK_OUT_FENCE_PTR connector_id = %d\n", id_);
+ return ret;
+}
+ }
return 0;
}
@@ -78,8 +95,13 @@ bool DrmConnector::external() const {
type_ == DRM_MODE_CONNECTOR_VGA;
}
+#define DRM_MODE_CONNECTOR_WRITEBACK 18
+bool DrmConnector::writeback() const {
+return type_ == DRM_MODE_CONNECTOR_WRITEBACK;
+}
+
bool DrmConnector::valid_type() const {
- return internal() || external();
+ return internal() || external() || writeback();
}
int DrmConnector::Upda
[PATCH RESEND v2 2/2] drm/xen-front: Provide kernel documentation
From: Oleksandr Andrushchenko Provide kernel documentation for the Xen para-virtualized frontend DRM driver. Signed-off-by: Oleksandr Andrushchenko --- Documentation/gpu/index.rst | 1 + Documentation/gpu/xen-front.rst | 77 + 2 files changed, 78 insertions(+) create mode 100644 Documentation/gpu/xen-front.rst diff --git a/Documentation/gpu/index.rst b/Documentation/gpu/index.rst index c36586dad29d..e31684af0a20 100644 --- a/Documentation/gpu/index.rst +++ b/Documentation/gpu/index.rst @@ -20,6 +20,7 @@ Linux GPU Driver Developer's Guide vga-switcheroo vgaarbiter bridge/dw-hdmi + xen-front todo .. only:: subproject and html diff --git a/Documentation/gpu/xen-front.rst b/Documentation/gpu/xen-front.rst new file mode 100644 index ..6ac0b75373c4 --- /dev/null +++ b/Documentation/gpu/xen-front.rst @@ -0,0 +1,77 @@ + +Xen para-virtualized frontend driver + +This frontend driver implements Xen para-virtualized display +according to the display protocol described at +include/xen/interface/io/displif.h + +Driver modes of operation in terms of display buffers used +== + +Depending on the requirements for the para-virtualized environment, namely +requirements dictated by the accompanying DRM/(v)GPU drivers running in both +host and guest environments, number of operating modes of para-virtualized +display driver are supported: + +- display buffers can be allocated by either frontend driver or backend +- display buffers can be allocated to be contiguous in memory or not + +Note! Frontend driver itself has no dependency on contiguous memory for +its operation. + +Buffers allocated by the frontend driver + + +The below modes of operation are configured at compile-time via +frontend driver's kernel configuration: + +With GEM CMA helpers + + This use-case is useful when used with accompanying DRM/vGPU driver in + guest domain which was designed to only work with contiguous buffers, + e.g. DRM driver based on GEM CMA helpers: such drivers can only import + contiguous PRIME buffers, thus requiring frontend driver to provide + such. In order to implement this mode of operation para-virtualized + frontend driver can be configured to use GEM CMA helpers. + +Without GEM CMA helpers +~~~ + If accompanying drivers can cope with non-contiguous memory then, to + lower pressure on CMA subsystem of the kernel, driver can allocate + buffers from system memory. + + Note! If used with accompanying DRM/(v)GPU drivers this mode of operation + may require IOMMU support on the platform, so accompanying DRM/vGPU + hardware can still reach display buffer memory while importing PRIME + buffers from the frontend driver. + +Buffers allocated by the backend + + +This mode of operation is run-time configured via guest domain configuration +through XenStore entries. + +For systems which do not provide IOMMU support, but having specific +requirements for display buffers it is possible to allocate such buffers +at backend side and share those with the frontend. +For example, if host domain is 1:1 mapped and has DRM/GPU hardware expecting +physically contiguous memory, this allows implementing zero-copying +use-cases. + +Note, while using this scenario the following should be considered: + +#. If guest domain dies then pages/grants received from the backend + cannot be claimed back + +#. Misbehaving guest may send too many requests to the + backend exhausting its grant references and memory + (consider this from security POV). + +Driver limitations +== + +#. Only primary plane without additional properties is supported. + +#. Only one video mode per connector supported which is configured via XenStore. + +#. All CRTCs operate at fixed frequency of 60Hz. -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] drm: Nuke the useless 'ret' variable from drm_mode_convert_umode()
On Tue, Mar 13, 2018 at 05:07:57PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> No need to store the return value in a variable since we don't have to
> do any unwinding.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_modes.c | 15 ---
> 1 file changed, 4 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
> index 5a8033fda4e3..4157250140b0 100644
> --- a/drivers/gpu/drm/drm_modes.c
> +++ b/drivers/gpu/drm/drm_modes.c
> @@ -1596,12 +1596,8 @@ int drm_mode_convert_umode(struct drm_device *dev,
> struct drm_display_mode *out,
> const struct drm_mode_modeinfo *in)
> {
> - int ret = -EINVAL;
> -
> - if (in->clock > INT_MAX || in->vrefresh > INT_MAX) {
> - ret = -ERANGE;
> - goto out;
> - }
> + if (in->clock > INT_MAX || in->vrefresh > INT_MAX)
> + return -ERANGE;
>
> out->clock = in->clock;
> out->hdisplay = in->hdisplay;
> @@ -1622,14 +1618,11 @@ int drm_mode_convert_umode(struct drm_device *dev,
>
> out->status = drm_mode_validate_driver(dev, out);
> if (out->status != MODE_OK)
> - goto out;
> + return -EINVAL;
>
> drm_mode_set_crtcinfo(out, CRTC_INTERLACE_HALVE_V);
>
> - ret = 0;
> -
> -out:
> - return ret;
> + return 0;
> }
>
> /**
> --
> 2.16.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RfC PATCH] Add udmabuf misc device
On Tue, Mar 13, 2018 at 04:48:26PM +0100, Gerd Hoffmann wrote:
> A driver to let userspace turn iovecs into dma-bufs.
>
> Use case: Allows qemu pass around dmabufs for the guest framebuffer.
> https://www.kraxel.org/cgit/qemu/log/?h=sirius/udmabuf has an
> experimental patch.
>
> Also allows qemu to export guest virtio-gpu resources as host dmabufs.
> Should be possible to use it to display guest wayland windows on the
> host display server. virtio-gpu ressources can be chunked so we will
> actually need multiple iovec entries. UNTESTED.
>
> Want collect some feedback on the general approach with this RfC series.
> Can this work? If not, better ideas?
>
> Question: Must this be hooked into some kind of mlock accounting, to
> limit the amout of memory userspace is allowed to pin this way? Or will
> get_user_pages_fast() handle that for me?
Either mlock account (because it's mlocked defacto), and get_user_pages
won't do that for you.
Or you write the full-blown userptr implementation, including mmu_notifier
support (see i915 or amdgpu), but that also requires Christian Königs
latest ->invalidate_mapping RFC for dma-buf (since atm exporting userptr
buffers is a no-go).
>
> Known issue: Driver API isn't complete yet. Need add some flags, for
> example to support read-only buffers.
dma-buf has no concept of read-only. I don't think we can even enforce
that (not many iommus can enforce this iirc), so pretty much need to
require r/w memory.
> Cc: David Airlie
> Cc: Tomeu Vizoso
> Signed-off-by: Gerd Hoffmann
btw there's also the hyperdmabuf stuff from the xen folks, but imo their
solution of forwarding the entire dma-buf api is over the top. This here
looks _much_ better, pls cc all the hyperdmabuf people on your next
version.
Overall I like the idea, but too lazy to review. Can maybe be bribed :-)
Oh, some kselftests for this stuff would be lovely.
-Daniel
> ---
> include/uapi/linux/udmabuf.h | 21
> drivers/dma-buf/udmabuf.c| 250
> +++
> drivers/dma-buf/Kconfig | 7 ++
> drivers/dma-buf/Makefile | 1 +
> 4 files changed, 279 insertions(+)
> create mode 100644 include/uapi/linux/udmabuf.h
> create mode 100644 drivers/dma-buf/udmabuf.c
>
> diff --git a/include/uapi/linux/udmabuf.h b/include/uapi/linux/udmabuf.h
> new file mode 100644
> index 00..fd2fa441fe
> --- /dev/null
> +++ b/include/uapi/linux/udmabuf.h
> @@ -0,0 +1,21 @@
> +/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
> +#ifndef _UAPI_LINUX_UDMABUF_H
> +#define _UAPI_LINUX_UDMABUF_H
> +
> +#include
> +#include
> +
> +struct udmabuf_iovec {
> + __u64 base;
> + __u64 len;
> +};
> +
> +struct udmabuf_create {
> + __u32 flags;
> + __u32 niov;
> + struct udmabuf_iovec iovs[];
> +};
> +
> +#define UDMABUF_CREATE _IOW(0x42, 0x23, struct udmabuf_create)
> +
> +#endif /* _UAPI_LINUX_UDMABUF_H */
> diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c
> new file mode 100644
> index 00..ec012d7ac7
> --- /dev/null
> +++ b/drivers/dma-buf/udmabuf.c
> @@ -0,0 +1,250 @@
> +/*
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +
> +struct udmabuf {
> + u32 pagecount;
> + struct page **pages;
> +};
> +
> +static int udmabuf_vm_fault(struct vm_fault *vmf)
> +{
> + struct vm_area_struct *vma = vmf->vma;
> + struct udmabuf *ubuf = vma->vm_private_data;
> +
> + if (WARN_ON(vmf->pgoff >= ubuf->pagecount))
> + return VM_FAULT_SIGBUS;
> +
> + vmf->page = ubuf->pages[vmf->pgoff];
> + get_page(vmf->page);
> + return 0;
> +}
> +
> +static const struct vm_operations_struct udmabuf_vm_ops = {
> + .fault = udmabuf_vm_fault,
> +};
> +
> +static int mmap_udmabuf(struct dma_buf *buf, struct vm_area_struct *vma)
> +{
> + struct udmabuf *ubuf = buf->priv;
> +
> + if ((vma->vm_flags & VM_SHARED) == 0)
> + return -EINVAL;
> +
> + vma->vm_ops = &udmabuf_vm_ops;
> + vma->vm_private_data = ubuf;
> + return 0;
> +}
> +
> +static struct sg_table *map_udmabuf(struct dma_buf_attachment *at,
> + enum dma_data_direction direction)
> +{
> + struct udmabuf *ubuf = at->dmabuf->priv;
> + struct sg_table *sg;
> +
> + sg = kzalloc(sizeof(*sg), GFP_KERNEL);
> + if (!sg)
> + goto err1;
> + if (sg_alloc_table_from_pages(sg, ubuf->pages, ubuf->pagecount,
> + 0, ubuf->pagecount << PAGE_SHIFT,
> + GFP_KERNEL) < 0)
> + goto err2;
> + if (!dma_map_sg(at->dev, sg->sgl, sg->nents, direction))
> + goto err3;
> +
> + return sg;
> +
> +err3:
> + sg_
Re: [PATCH 1/4] dma-buf: add optional invalidate_mappings callback
On Tue, Mar 13, 2018 at 04:52:02PM +0100, Christian König wrote: > Am 13.03.2018 um 16:17 schrieb Daniel Vetter: > > [SNIP] > > > > I think a helper which both unmaps _and_ waits for all the fences to > > > > clear > > > > would be best, with some guarantees that it'll either fail or all the > > > > mappings _will_ be gone. The locking for that one will be hilarious, > > > > since > > > > we need to figure out dmabuf->lock vs. the reservation. I kinda prefer > > > > we > > > > throw away the dmabuf->lock and superseed it entirely by the reservation > > > > lock. > > > Big NAK on that. The whole API is asynchronously, e.g. we never block for > > > any operation to finish. > > > > > > Otherwise you run into big trouble with cross device GPU resets and stuff > > > like that. > > But how will the unmapping work then? You can't throw the sg list away > > before the dma stopped. The dma only stops once the fence is signalled. > > The importer can't call dma_buf_detach because the reservation lock is > > hogged already by the exporter trying to unmap everything. > > > > How is this supposed to work? > > Even after invalidation the sg list stays alive until it is explicitly > destroyed by the importer using dma_buf_unmap_attachment() which in turn is > only allowed after all fences have signaled. > > The implementation is in ttm_bo_pipeline_gutting(), basically we use the > same functionality as for pipelined moves/evictions which hangs the old > backing store on a dummy object and destroys it after all fences signaled. > > While the old sg list is still about to be destroyed the importer can > request a new sg list for the new location of the DMA-buf using > dma_buf_map_attachment(). This new location becomes valid after the move > fence in the reservation object is signaled. > > So from the CPU point of view multiple sg list could exists at the same time > which allows us to have a seamless transition from the old to the new > location from the GPU point of view. Ok, so plan is to support fully pipeline moves and everything, with the old sg tables lazily cleaned up. I was thinking more about evicting stuff and throwing it out, where there's not going to be any new sg list but the object is going to be swapped out. I think some state flow charts (we can do SVG or DOT) in the kerneldoc would be sweet. > > Re GPU might cause a deadlock: Isn't that already a problem if you hold > > reservations of buffers used on other gpus, which want those reservations > > to complete the gpu reset, but that gpu reset blocks some fence that the > > reservation holder is waiting for? > > Correct, that's why amdgpu and TTM tries quite hard to never wait for a > fence while a reservation object is locked. We might have a fairly huge mismatch of expectations here :-/ > The only use case I haven't fixed so far is reaping deleted object during > eviction, but that is only a matter of my free time to fix it. Yeah, this is the hard one. In general the assumption is that dma_fence will get signalled no matter what you're doing, assuming the only thing you need is to not block interrupts. The i915 gpu reset logic to make that work is a bit a work of art ... If we expect amdgpu and i915 to cooperate with shared buffers I guess one has to give in. No idea how to do that best. > > We have tons of fun with deadlocks against GPU resets, and loots of > > testcases, and I kinda get the impression amdgpu is throwing a lot of > > issues under the rug through trylock tricks that shut up lockdep, but > > don't fix much really. > > Hui? Why do you think that? The only trylock I'm aware of is during eviction > and there it isn't a problem. mmap fault handler had one too last time I looked, and it smelled fishy. > > btw adding cross-release lockdep annotations for fences will probably turn > > up _lots_ more bugs in this area. > > At least for amdgpu that should be handled by now. You're sure? :-) Trouble is that cross-release wasn't even ever enabled, much less anyone typed the dma_fence annotations. And just cross-release alone turned up _lost_ of deadlocks in i915 between fences, async workers (userptr, gpu reset) and core mm stuff. I'd be seriously surprised if it wouldn't find an entire rats nest of issues around dma_fence once we enable it. -Daniel > > > > > + * > > > > > + * New mappings can be created immediately, but can't be used > > > > > before the > > > > > + * exclusive fence in the dma_bufs reservation object is > > > > > signaled. > > > > > + */ > > > > > + void (*invalidate_mappings)(struct dma_buf_attachment *attach); > > > > Bunch of questions about exact semantics, but I very much like this. > > > > And I > > > > think besides those technical details, the overall approach seems sound. > > > Yeah this initial implementation was buggy like hell. Just wanted to > > > confirm > > > that the idea is going in the right direction. > > I wanted this 7 years ago, idea very much acked :
Re: [RFC PATCH 00/13] SVM (share virtual memory) with HMM in nouveau
On Mon, Mar 12, 2018 at 11:14:47PM -0700, John Hubbard wrote: > On 03/12/2018 10:50 AM, Jerome Glisse wrote: [...] > Yes, on NVIDIA GPUs, the Host/FIFO unit is limited to 40-bit addresses, so > things such as the following need to be below (1 << 40), and also accessible > to both CPU (user space) and GPU hardware. > -- command buffers (CPU user space driver fills them, GPU consumes them), > -- semaphores (here, a GPU-centric term, rather than OS-type: these are >memory locations that, for example, the GPU hardware might write to, in >order to indicate work completion; there are other uses as well), > -- a few other things most likely (this is not a complete list). > > So what I'd tentatively expect that to translate into in the driver stack is, > approximately: > > -- User space driver code mmap's an area below (1 << 40). It's hard to > avoid this, >given that user space needs access to the area (for filling out command >buffers and monitoring semaphores, that sort of thing). Then > suballocate >from there using mmap's MAP_FIXED or (future-ish) MAP_FIXED_SAFE flags. > >...glancing at the other fork of this thread, I think that is exactly > what >Felix is saying, too. So that's good. > > -- The user space program sits above the user space driver, and although > the >program could, in theory, interfere with this mmap'd area, that would > be >wrong in the same way that mucking around with malloc'd areas (outside > of >malloc() itself) is wrong. So I don't see any particular need to do > much >more than the above. I am worried that rogue program (i am not worried about buggy program if people shoot themself in the foot they should feel the pain) could use that to abuse channel to do something harmful. I am not familiar enough with the hardware to completely rule out such scenario. I do believe hardware with userspace queue support have the necessary boundary to keep thing secure as i would assume for those the hardware engineers had to take security into consideration. Note that in my patchset the code that monitor the special vma is small something like 20lines of code that only get call if something happen to the reserved area. So i believe it is worth having such thing, cost is low for little extra peace of mind :) Cheers, Jérôme ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/4] dma-buf: add optional invalidate_mappings callback
Am 13.03.2018 um 16:17 schrieb Daniel Vetter: [SNIP] I think a helper which both unmaps _and_ waits for all the fences to clear would be best, with some guarantees that it'll either fail or all the mappings _will_ be gone. The locking for that one will be hilarious, since we need to figure out dmabuf->lock vs. the reservation. I kinda prefer we throw away the dmabuf->lock and superseed it entirely by the reservation lock. Big NAK on that. The whole API is asynchronously, e.g. we never block for any operation to finish. Otherwise you run into big trouble with cross device GPU resets and stuff like that. But how will the unmapping work then? You can't throw the sg list away before the dma stopped. The dma only stops once the fence is signalled. The importer can't call dma_buf_detach because the reservation lock is hogged already by the exporter trying to unmap everything. How is this supposed to work? Even after invalidation the sg list stays alive until it is explicitly destroyed by the importer using dma_buf_unmap_attachment() which in turn is only allowed after all fences have signaled. The implementation is in ttm_bo_pipeline_gutting(), basically we use the same functionality as for pipelined moves/evictions which hangs the old backing store on a dummy object and destroys it after all fences signaled. While the old sg list is still about to be destroyed the importer can request a new sg list for the new location of the DMA-buf using dma_buf_map_attachment(). This new location becomes valid after the move fence in the reservation object is signaled. So from the CPU point of view multiple sg list could exists at the same time which allows us to have a seamless transition from the old to the new location from the GPU point of view. Re GPU might cause a deadlock: Isn't that already a problem if you hold reservations of buffers used on other gpus, which want those reservations to complete the gpu reset, but that gpu reset blocks some fence that the reservation holder is waiting for? Correct, that's why amdgpu and TTM tries quite hard to never wait for a fence while a reservation object is locked. The only use case I haven't fixed so far is reaping deleted object during eviction, but that is only a matter of my free time to fix it. We have tons of fun with deadlocks against GPU resets, and loots of testcases, and I kinda get the impression amdgpu is throwing a lot of issues under the rug through trylock tricks that shut up lockdep, but don't fix much really. Hui? Why do you think that? The only trylock I'm aware of is during eviction and there it isn't a problem. btw adding cross-release lockdep annotations for fences will probably turn up _lots_ more bugs in this area. At least for amdgpu that should be handled by now. +* +* New mappings can be created immediately, but can't be used before the +* exclusive fence in the dma_bufs reservation object is signaled. +*/ + void (*invalidate_mappings)(struct dma_buf_attachment *attach); Bunch of questions about exact semantics, but I very much like this. And I think besides those technical details, the overall approach seems sound. Yeah this initial implementation was buggy like hell. Just wanted to confirm that the idea is going in the right direction. I wanted this 7 years ago, idea very much acked :-) Ok, thanks. Good to know. Christian. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RfC PATCH] Add udmabuf misc device
A driver to let userspace turn iovecs into dma-bufs.
Use case: Allows qemu pass around dmabufs for the guest framebuffer.
https://www.kraxel.org/cgit/qemu/log/?h=sirius/udmabuf has an
experimental patch.
Also allows qemu to export guest virtio-gpu resources as host dmabufs.
Should be possible to use it to display guest wayland windows on the
host display server. virtio-gpu ressources can be chunked so we will
actually need multiple iovec entries. UNTESTED.
Want collect some feedback on the general approach with this RfC series.
Can this work? If not, better ideas?
Question: Must this be hooked into some kind of mlock accounting, to
limit the amout of memory userspace is allowed to pin this way? Or will
get_user_pages_fast() handle that for me?
Known issue: Driver API isn't complete yet. Need add some flags, for
example to support read-only buffers.
Cc: David Airlie
Cc: Tomeu Vizoso
Signed-off-by: Gerd Hoffmann
---
include/uapi/linux/udmabuf.h | 21
drivers/dma-buf/udmabuf.c| 250 +++
drivers/dma-buf/Kconfig | 7 ++
drivers/dma-buf/Makefile | 1 +
4 files changed, 279 insertions(+)
create mode 100644 include/uapi/linux/udmabuf.h
create mode 100644 drivers/dma-buf/udmabuf.c
diff --git a/include/uapi/linux/udmabuf.h b/include/uapi/linux/udmabuf.h
new file mode 100644
index 00..fd2fa441fe
--- /dev/null
+++ b/include/uapi/linux/udmabuf.h
@@ -0,0 +1,21 @@
+/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
+#ifndef _UAPI_LINUX_UDMABUF_H
+#define _UAPI_LINUX_UDMABUF_H
+
+#include
+#include
+
+struct udmabuf_iovec {
+ __u64 base;
+ __u64 len;
+};
+
+struct udmabuf_create {
+ __u32 flags;
+ __u32 niov;
+ struct udmabuf_iovec iovs[];
+};
+
+#define UDMABUF_CREATE _IOW(0x42, 0x23, struct udmabuf_create)
+
+#endif /* _UAPI_LINUX_UDMABUF_H */
diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c
new file mode 100644
index 00..ec012d7ac7
--- /dev/null
+++ b/drivers/dma-buf/udmabuf.c
@@ -0,0 +1,250 @@
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+struct udmabuf {
+ u32 pagecount;
+ struct page **pages;
+};
+
+static int udmabuf_vm_fault(struct vm_fault *vmf)
+{
+ struct vm_area_struct *vma = vmf->vma;
+ struct udmabuf *ubuf = vma->vm_private_data;
+
+ if (WARN_ON(vmf->pgoff >= ubuf->pagecount))
+ return VM_FAULT_SIGBUS;
+
+ vmf->page = ubuf->pages[vmf->pgoff];
+ get_page(vmf->page);
+ return 0;
+}
+
+static const struct vm_operations_struct udmabuf_vm_ops = {
+ .fault = udmabuf_vm_fault,
+};
+
+static int mmap_udmabuf(struct dma_buf *buf, struct vm_area_struct *vma)
+{
+ struct udmabuf *ubuf = buf->priv;
+
+ if ((vma->vm_flags & VM_SHARED) == 0)
+ return -EINVAL;
+
+ vma->vm_ops = &udmabuf_vm_ops;
+ vma->vm_private_data = ubuf;
+ return 0;
+}
+
+static struct sg_table *map_udmabuf(struct dma_buf_attachment *at,
+ enum dma_data_direction direction)
+{
+ struct udmabuf *ubuf = at->dmabuf->priv;
+ struct sg_table *sg;
+
+ sg = kzalloc(sizeof(*sg), GFP_KERNEL);
+ if (!sg)
+ goto err1;
+ if (sg_alloc_table_from_pages(sg, ubuf->pages, ubuf->pagecount,
+ 0, ubuf->pagecount << PAGE_SHIFT,
+ GFP_KERNEL) < 0)
+ goto err2;
+ if (!dma_map_sg(at->dev, sg->sgl, sg->nents, direction))
+ goto err3;
+
+ return sg;
+
+err3:
+ sg_free_table(sg);
+err2:
+ kfree(sg);
+err1:
+ return ERR_PTR(-ENOMEM);
+}
+
+static void unmap_udmabuf(struct dma_buf_attachment *at,
+ struct sg_table *sg,
+ enum dma_data_direction direction)
+{
+ sg_free_table(sg);
+ kfree(sg);
+}
+
+static void release_udmabuf(struct dma_buf *buf)
+{
+ struct udmabuf *ubuf = buf->priv;
+ pgoff_t pg;
+
+ for (pg = 0; pg < ubuf->pagecount; pg++)
+ put_page(ubuf->pages[pg]);
+ kfree(ubuf->pages);
+ kfree(ubuf);
+}
+
+static void *kmap_atomic_udmabuf(struct dma_buf *buf, unsigned long offset)
+{
+ struct udmabuf *ubuf = buf->priv;
+ struct page *page = ubuf->pages[offset >> PAGE_SHIFT];
+
+ return kmap_atomic(page);
+}
+
+static void *kmap_udmabuf(struct dma_buf *buf, unsigned long offset)
+{
+ struct udmabuf *ubuf = buf->priv;
+ struct page *page = ubuf->pages[offset >> PAGE_SHIFT];
+
+ return kmap(page);
+}
+
+static struct dma_buf_ops udmabuf_ops = {
+ .map_dma_buf = map_udmabuf,
+ .unmap_dma_buf= unm
Re: [PATCH v2 1/3] drm: Add the optional .fb_modifier() hook
On Tue, Mar 13, 2018 at 04:35:02PM +0100, Michel Dänzer wrote: > On 2018-03-13 04:20 PM, Daniel Vetter wrote: > > On Tue, Mar 13, 2018 at 03:38:38PM +0100, Michel Dänzer wrote: > >> On 2018-03-13 03:28 PM, Ville Syrjala wrote: > >>> From: Ville Syrjälä > >>> > >>> To make it possible for the core to check the fb pixel format and > >>> modifier, we need to first ask the driver to deduce the modifier > >>> when the request does not explicitly specify one. > >>> > >>> Add a new .fb_modifier() hook for that purpose and convert i915 > >>> and vc4 to make use if it. All other drivers seem to currently > >>> assume linear when the request does not specify anything else, > >>> [...] > >> > >> That's not true at least for the amdgpu and radeon drivers. The tiling > >> mode is communicated via BO metadata. > > > > But atm amdgpu and radeon also don't support explicit modifiers in the > > kernel driver, so it again all checks out. Or should at least. > > Sounds like I misunderstood that this is trying to guess modifiers for > all drivers. So far, so good if so. Somehow I convinced myself that amdgpu already had some modifier support. But looks like I was mistaken. > > Once you add modifier support, you need to wire up all the bits and the > > rigth default selection, and it should again pan out. > > Well, this change allows a driver not to wire up the fb_modifier hook, > and just assumes linear in that case. Seems like an accident waiting to > happen, but I'll leave it to you guys. That's already the case with the current code. mode_cmd->modifier[0] will be 0 when when DRM_MODE_FB_MODIFIERS isn't specified, which is the same thing as DRM_FORMAT_MOD_LINEAR. So if the driver doesn't change it before calling drm_helper_mode_fill_fb_struct() you end up with fb->modifier == DRM_FORMAT_MOD_LINEAR. -- Ville Syrjälä Intel OTC ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
