[PATCH v3 0/7] include: add setbits32/clrbits32/clrsetbits32/setbits64/clrbits64/clrsetbits64
Hello This patchset adds a new set of functions which are open-coded in lot of place. Basicly the pattern is always the same, "read, modify a bit, write" some driver and the powerpc arch already have thoses pattern them as functions. (like ahci_sunxi.c or dwmac-meson8b) The first patch rename some powerpc functions for being consistent with the new name convention. The second patch adds the header with all setbits functions. The third patch is a try to implement a coccinelle semantic patch to find all place where xxxbits function could be used. It should not be merged since it is un-finalized. For the moment, the "add setbits.h header" is not working and need a future coccinelle version. The four last patch are example of some drivers conversion. Thoses patchs give an example of the reduction of code won by using xxxbits32. I would like to thanks Julia Lawall for her help on the coccinelle patch. Note that I dont know which maintainer will take the linux/setbits.h include patch. Regards Changes since v2: - Fixed patch title - Fixed style problems - shorted macro arguments name Changes since v1: - renamed LE functions to _leXX - updated coccinnelle patch with JLawall's comments Corentin Labbe (7): powerpc: rename setbits32/clrbits32 to setbits_be32/clrbits_be32 include: add setbits_leXX/clrbits_leXX/clrsetbits_leXX in linux/setbits.h coccinelle: add xxxsetbits_leXX converting spatch ata: ahci_sunxi: use xxxsetbitsi_le32 functions net: ethernet: stmmac: dwmac-sun8i: use xxxsetbits_le32 drm: meson: use xxxsetbits_le32 net: stmmac: dwmac-meson8b: use xxxsetbits_le32 arch/powerpc/include/asm/fsl_lbc.h| 2 +- arch/powerpc/include/asm/io.h | 4 +- arch/powerpc/platforms/44x/canyonlands.c | 4 +- arch/powerpc/platforms/4xx/gpio.c | 28 +- arch/powerpc/platforms/512x/pdm360ng.c| 6 +- arch/powerpc/platforms/52xx/mpc52xx_common.c | 6 +- arch/powerpc/platforms/52xx/mpc52xx_gpt.c | 12 +- arch/powerpc/platforms/82xx/ep8248e.c | 2 +- arch/powerpc/platforms/82xx/km82xx.c | 6 +- arch/powerpc/platforms/82xx/mpc8272_ads.c | 10 +- arch/powerpc/platforms/82xx/pq2.c | 2 +- arch/powerpc/platforms/82xx/pq2ads-pci-pic.c | 4 +- arch/powerpc/platforms/82xx/pq2fads.c | 10 +- arch/powerpc/platforms/83xx/km83xx.c | 6 +- arch/powerpc/platforms/83xx/mpc836x_mds.c | 2 +- arch/powerpc/platforms/85xx/mpc85xx_mds.c | 2 +- arch/powerpc/platforms/85xx/mpc85xx_pm_ops.c | 4 +- arch/powerpc/platforms/85xx/mpc85xx_rdb.c | 2 +- arch/powerpc/platforms/85xx/p1022_ds.c| 6 +- arch/powerpc/platforms/85xx/p1022_rdk.c | 6 +- arch/powerpc/platforms/85xx/t1042rdb_diu.c| 6 +- arch/powerpc/platforms/85xx/twr_p102x.c | 2 +- arch/powerpc/platforms/86xx/mpc8610_hpcd.c| 6 +- arch/powerpc/platforms/8xx/adder875.c | 2 +- arch/powerpc/platforms/8xx/m8xx_setup.c | 4 +- arch/powerpc/platforms/8xx/mpc86xads_setup.c | 4 +- arch/powerpc/platforms/8xx/mpc885ads_setup.c | 28 +- .../platforms/embedded6xx/flipper-pic.c | 6 +- arch/powerpc/platforms/embedded6xx/hlwd-pic.c | 8 +- arch/powerpc/platforms/embedded6xx/wii.c | 12 +- arch/powerpc/sysdev/cpm1.c| 26 +- arch/powerpc/sysdev/cpm2.c| 16 +- arch/powerpc/sysdev/cpm_common.c | 4 +- arch/powerpc/sysdev/fsl_85xx_l2ctlr.c | 16 +- arch/powerpc/sysdev/fsl_lbc.c | 2 +- arch/powerpc/sysdev/fsl_pci.c | 12 +- arch/powerpc/sysdev/fsl_pmc.c | 2 +- arch/powerpc/sysdev/fsl_rcpm.c| 74 +-- arch/powerpc/sysdev/fsl_rio.c | 4 +- arch/powerpc/sysdev/fsl_rmu.c | 9 +- arch/powerpc/sysdev/mpic_timer.c | 12 +- drivers/ata/ahci_sunxi.c | 62 +-- drivers/gpu/drm/meson/meson_crtc.c| 14 +- drivers/gpu/drm/meson/meson_dw_hdmi.c | 33 +- drivers/gpu/drm/meson/meson_plane.c | 13 +- drivers/gpu/drm/meson/meson_registers.h | 3 - drivers/gpu/drm/meson/meson_venc.c| 13 +- drivers/gpu/drm/meson/meson_venc_cvbs.c | 4 +- drivers/gpu/drm/meson/meson_viu.c | 65 +-- drivers/gpu/drm/meson/meson_vpp.c | 22 +- .../ethernet/stmicro/stmmac/dwmac-meson8b.c | 56 +- .../net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 62 +-- include/linux/setbits.h | 84 +++ scripts/add_new_include_in_source.py | 61 +++ scripts/coccinelle/misc/setbits32.cocci | 487 ++ .../coccinelle/misc/setbits32_relaxed.cocci | 487 ++ scripts/coccinelle/misc/setbits64.cocci | 487 ++ scripts/coccinelle/misc/setbits_dev.cocci | 235 + 58 files changed, 2172 insertions(+), 395 deletions(-) create mode
Re: [PATCH v3 2/7] include: add setbits_leXX/clrbits_leXX/clrsetbits_leXX in linux/setbits.h
On Wed, 24 Oct 2018 07:35:48 +, Corentin Labbe wrote: > This patch adds setbits_le32/clrbits_le32/clrsetbits_le32 and > setbits_le64/clrbits_le64/clrsetbits_le64 in linux/setbits.h header. > > Signed-off-by: Corentin Labbe Did you have a look at all the functions defined in bitfield.h? (including the magic macro-generated ones?) Perhaps those could be used here? I also share the concerns about the non-atomic RMW. Obviously correct beats short IMHO. > diff --git a/include/linux/setbits.h b/include/linux/setbits.h > new file mode 100644 > index ..c82faf8d7fe4 > --- /dev/null > +++ b/include/linux/setbits.h > @@ -0,0 +1,84 @@ > +/* SPDX-License-Identifier: GPL-2.0 */ > +#ifndef __LINUX_SETBITS_H > +#define __LINUX_SETBITS_H > + > +#include > + > +#define __setbits(rfn, wfn, addr, set) wfn((rfn(addr) | (set)), addr) > +#define __clrbits(rfn, wfn, addr, mask) wfn((rfn(addr) & ~(mask)), addr) > +#define __clrsetbits(rfn, wfn, addr, mask, set) wfn(((rfn(addr) & ~(mask)) | > (set)), addr) > +#define __setclrbits(rfn, wfn, addr, mask, set) wfn(((rfn(addr) | (set)) & > ~(mask)), addr) > + > +#ifndef setbits_le32 > +#define setbits_le32(addr, set) __setbits(readl, writel, addr, set) > +#endif > +#ifndef setbits_le32_relaxed > +#define setbits_le32_relaxed(addr, set) __setbits(readl_relaxed, > writel_relaxed, \ > +addr, set) > +#endif > + > +#ifndef clrbits_le32 > +#define clrbits_le32(addr, mask) __clrbits(readl, writel, addr, mask) > +#endif > +#ifndef clrbits_le32_relaxed > +#define clrbits_le32_relaxed(addr, mask) __clrbits(readl_relaxed, > writel_relaxed, \ > + addr, mask) > +#endif > + > +#ifndef clrsetbits_le32 > +#define clrsetbits_le32(addr, mask, set) __clrsetbits(readl, writel, addr, > mask, set) > +#endif > +#ifndef clrsetbits_le32_relaxed > +#define clrsetbits_le32_relaxed(addr, mask, set) __clrsetbits(readl_relaxed, > \ > +writel_relaxed, \ > +addr, mask, set) > +#endif > + > +#ifndef setclrbits_le32 > +#define setclrbits_le32(addr, mask, set) __setclrbits(readl, writel, addr, > mask, set) > +#endif > +#ifndef setclrbits_le32_relaxed > +#define setclrbits_le32_relaxed(addr, mask, set) __setclrbits(readl_relaxed, > \ > +writel_relaxed, \ > +addr, mask, set) > +#endif > + > +/* We cannot use CONFIG_64BIT as some x86 drivers use non-atomicwriteq() */ > +#if defined(writeq) && defined(readq) > +#ifndef setbits_le64 > +#define setbits_le64(addr, set) __setbits(readq, writeq, addr, set) > +#endif > +#ifndef setbits_le64_relaxed > +#define setbits_le64_relaxed(addr, set) __setbits(readq_relaxed, > writeq_relaxed, \ > +addr, set) > +#endif > + > +#ifndef clrbits_le64 > +#define clrbits_le64(addr, mask) __clrbits(readq, writeq, addr, mask) > +#endif > +#ifndef clrbits_le64_relaxed > +#define clrbits_le64_relaxed(addr, mask) __clrbits(readq_relaxed, > writeq_relaxed, \ > + addr, mask) > +#endif > + > +#ifndef clrsetbits_le64 > +#define clrsetbits_le64(addr, mask, set) __clrsetbits(readq, writeq, addr, > mask, set) > +#endif > +#ifndef clrsetbits_le64_relaxed > +#define clrsetbits_le64_relaxed(addr, mask, set) __clrsetbits(readq_relaxed, > \ > +writeq_relaxed, \ > +addr, mask, set) > +#endif > + > +#ifndef setclrbits_le64 > +#define setclrbits_le64(addr, mask, set) __setclrbits(readq, writeq, addr, > mask, set) > +#endif > +#ifndef setclrbits_le64_relaxed > +#define setclrbits_le64_relaxed(addr, mask, set) __setclrbits(readq_relaxed, > \ > +writeq_relaxed, \ > +addr, mask, set) > +#endif > + > +#endif /* writeq/readq */ > + > +#endif /* __LINUX_SETBITS_H */ ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 3/7 DONOTMERGE] coccinelle: add xxxsetbits_leXX converting spatch
This patch add a spatch which convert all open coded of
setbits_le32/clrbits_le32/clrsetbits_le32
and their 64 bits counterparts.
Note that 64 and 32_relaxed are generated via
cp scripts/coccinelle/misc/setbits32.cocci
scripts/coccinelle/misc/setbits32_relaxed.cocci
sed -i 's,readl,readl_relaxed,' scripts/coccinelle/misc/setbits32_relaxed.cocci
sed -i 's,writel,writel_relaxed,'
scripts/coccinelle/misc/setbits32_relaxed.cocci
sed -i 's,setbits_le32,setbits_le32_relaxed,g'
scripts/coccinelle/misc/setbits32_relaxed.cocci
sed -i 's,clrbits_le32,clrbits_le32_relaxed,g'
scripts/coccinelle/misc/setbits32_relaxed.cocci
cp scripts/coccinelle/misc/setbits32.cocci
scripts/coccinelle/misc/setbits64.cocci
sed -i 's,readl,readq,' scripts/coccinelle/misc/setbits64.cocci
sed -i 's,writel,writeq,' scripts/coccinelle/misc/setbits64.cocci
sed -i 's,le32,le64,' scripts/coccinelle/misc/setbits64.cocci
Signed-off-by: Corentin Labbe
---
scripts/add_new_include_in_source.py | 61 +++
scripts/coccinelle/misc/setbits32.cocci | 487 ++
.../coccinelle/misc/setbits32_relaxed.cocci | 487 ++
scripts/coccinelle/misc/setbits64.cocci | 487 ++
scripts/coccinelle/misc/setbits_dev.cocci | 235 +
5 files changed, 1757 insertions(+)
create mode 100755 scripts/add_new_include_in_source.py
create mode 100644 scripts/coccinelle/misc/setbits32.cocci
create mode 100644 scripts/coccinelle/misc/setbits32_relaxed.cocci
create mode 100644 scripts/coccinelle/misc/setbits64.cocci
create mode 100644 scripts/coccinelle/misc/setbits_dev.cocci
diff --git a/scripts/add_new_include_in_source.py
b/scripts/add_new_include_in_source.py
new file mode 100755
index ..a43ccfbf9921
--- /dev/null
+++ b/scripts/add_new_include_in_source.py
@@ -0,0 +1,61 @@
+#!/usr/bin/env python
+
+# add
+
+import os, sys
+import re
+import shutil
+
+if len(sys.argv) < 2:
+print("Usage: %s pathtosourcefile" % (sys.argv[0]))
+sys.exit(1)
+
+found_global_headers = False
+found_local_headers = False
+#first check it does already here
+with open(sys.argv[1], 'r') as fp:
+for line in fp:
+if re.search("#include \n", line):
+print("INFO: header already here")
+sys.exit(0)
+if re.search("^#include <", line):
+found_global_headers = True
+if re.search("^#include \"", line):
+found_local_headers = True
+fp.close()
+
+if not found_global_headers and not found_local_headers:
+print("No header included do it at hand")
+sys.exit(1)
+
+if found_global_headers:
+done = False
+inheader = False
+with open("%s.new" % sys.argv[1], 'w') as fw:
+with open(sys.argv[1], 'r') as fp:
+for line in fp:
+if re.search("^#include = "s" and line[17] >= "e" and
line[18] >= "t" and line[19] >= 'b'):
+done = True
+fw.write("#include \n")
+if not done and not re.search("^#include \n")
+fw.write(line)
+fw.close()
+fp.close()
+else:
+done = False
+with open("%s.new" % sys.argv[1], 'w') as fw:
+with open(sys.argv[1], 'r') as fp:
+for line in fp:
+if not done and re.search("^#include \"", line):
+fw.write("#include \n")
+done = True
+fw.write(line)
+fw.close()
+fp.close()
+
+shutil.move("%s.new" % sys.argv[1], sys.argv[1])
+print("%s done" % sys.argv[1])
diff --git a/scripts/coccinelle/misc/setbits32.cocci
b/scripts/coccinelle/misc/setbits32.cocci
new file mode 100644
index ..71400cac6830
--- /dev/null
+++ b/scripts/coccinelle/misc/setbits32.cocci
@@ -0,0 +1,487 @@
+// SPDX-License-Identifier: GPL-2.0
+// Confidence: High
+// Copyright: (c) 2018 Corentin LABBE
+
+virtual patch
+
+@p_clrsetbits_le32_l4@
+local idexpression rr;
+expression addr;
+expression set;
+expression clear;
+expression e;
+position p;
+@@
+
+- rr@p = readl(addr);
+- rr &= ~clear;
+- rr |= set;
+- writel(rr, addr);
++ clrsetbits_le32(addr, clear, set);
+ ... when != rr
+? rr = e
+
+@script:python depends on p_clrsetbits_le32_l4@
+p1 << p_clrsetbits_le32_l4.p;
+@@
+list.append(p1[0].file)
+
+
+@p_clrsetbits_le32_l3@
+local idexpression rr;
+expression addr;
+expression set;
+expression clear;
+expression e;
+position p;
+@@
+
+- rr@p = readl(addr);
+- rr &= ~clear | set;
+- writel(rr, addr);
++ clrsetbits_le32(addr, clear, set);
+ ... when != rr
+? rr = e
+
+@script:python depends on p_clrsetbits_le32_l3@
+p1 << p_clrsetbits_le32_l3.p;
+@@
+list.append(p1[0].file)
+
+
+
+@p_clrsetbits_oneliner@
+expression addr;
+expression set;
+expression mask;
+position p;
+@@
+- writel@p(readl(addr) & ~mask | set, addr);
++ clrsetbits_le32(addr, mask, set);
+
+@script:python depends on p_clrsetbits_oneliner@
+p1 << p_clrsetbits_oneliner.p;
+@@
+list.append(p1[0].file)
+
+
+@p_clrsetbits_oneliner_b@
[PATCH v3 5/7] net: ethernet: stmmac: dwmac-sun8i: use xxxsetbits_le32
This patch convert dwmac-sun8i driver to use all xxxsetbits_le32 functions.
Signed-off-by: Corentin Labbe
---
.../net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 62 +--
1 file changed, 16 insertions(+), 46 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
index f9a61f90cfbc..74067a59af50 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
#include "stmmac.h"
#include "stmmac_platform.h"
@@ -342,50 +343,30 @@ static void sun8i_dwmac_disable_dma_irq(void __iomem
*ioaddr, u32 chan)
static void sun8i_dwmac_dma_start_tx(void __iomem *ioaddr, u32 chan)
{
- u32 v;
-
- v = readl(ioaddr + EMAC_TX_CTL1);
- v |= EMAC_TX_DMA_START;
- v |= EMAC_TX_DMA_EN;
- writel(v, ioaddr + EMAC_TX_CTL1);
+ setbits_le32(ioaddr + EMAC_TX_CTL1,
+EMAC_TX_DMA_START | EMAC_TX_DMA_EN);
}
static void sun8i_dwmac_enable_dma_transmission(void __iomem *ioaddr)
{
- u32 v;
-
- v = readl(ioaddr + EMAC_TX_CTL1);
- v |= EMAC_TX_DMA_START;
- v |= EMAC_TX_DMA_EN;
- writel(v, ioaddr + EMAC_TX_CTL1);
+ setbits_le32(ioaddr + EMAC_TX_CTL1,
+EMAC_TX_DMA_START | EMAC_TX_DMA_EN);
}
static void sun8i_dwmac_dma_stop_tx(void __iomem *ioaddr, u32 chan)
{
- u32 v;
-
- v = readl(ioaddr + EMAC_TX_CTL1);
- v &= ~EMAC_TX_DMA_EN;
- writel(v, ioaddr + EMAC_TX_CTL1);
+ clrbits_le32(ioaddr + EMAC_TX_CTL1, EMAC_TX_DMA_EN);
}
static void sun8i_dwmac_dma_start_rx(void __iomem *ioaddr, u32 chan)
{
- u32 v;
-
- v = readl(ioaddr + EMAC_RX_CTL1);
- v |= EMAC_RX_DMA_START;
- v |= EMAC_RX_DMA_EN;
- writel(v, ioaddr + EMAC_RX_CTL1);
+ setbits_le32(ioaddr + EMAC_RX_CTL1,
+EMAC_RX_DMA_START | EMAC_RX_DMA_EN);
}
static void sun8i_dwmac_dma_stop_rx(void __iomem *ioaddr, u32 chan)
{
- u32 v;
-
- v = readl(ioaddr + EMAC_RX_CTL1);
- v &= ~EMAC_RX_DMA_EN;
- writel(v, ioaddr + EMAC_RX_CTL1);
+ clrbits_le32(ioaddr + EMAC_RX_CTL1, EMAC_RX_DMA_EN);
}
static int sun8i_dwmac_dma_interrupt(void __iomem *ioaddr,
@@ -578,7 +559,6 @@ static void sun8i_dwmac_set_umac_addr(struct
mac_device_info *hw,
unsigned int reg_n)
{
void __iomem *ioaddr = hw->pcsr;
- u32 v;
if (!addr) {
writel(0, ioaddr + EMAC_MACADDR_HI(reg_n));
@@ -588,9 +568,8 @@ static void sun8i_dwmac_set_umac_addr(struct
mac_device_info *hw,
stmmac_set_mac_addr(ioaddr, addr, EMAC_MACADDR_HI(reg_n),
EMAC_MACADDR_LO(reg_n));
if (reg_n > 0) {
- v = readl(ioaddr + EMAC_MACADDR_HI(reg_n));
- v |= MAC_ADDR_TYPE_DST;
- writel(v, ioaddr + EMAC_MACADDR_HI(reg_n));
+ setbits_le32(ioaddr + EMAC_MACADDR_HI(reg_n),
+MAC_ADDR_TYPE_DST);
}
}
@@ -608,11 +587,8 @@ static void sun8i_dwmac_get_umac_addr(struct
mac_device_info *hw,
static int sun8i_dwmac_rx_ipc_enable(struct mac_device_info *hw)
{
void __iomem *ioaddr = hw->pcsr;
- u32 v;
- v = readl(ioaddr + EMAC_RX_CTL0);
- v |= EMAC_RX_DO_CRC;
- writel(v, ioaddr + EMAC_RX_CTL0);
+ setbits_le32(ioaddr + EMAC_RX_CTL0, EMAC_RX_DO_CRC);
return 1;
}
@@ -662,21 +638,15 @@ static void sun8i_dwmac_flow_ctrl(struct mac_device_info
*hw,
unsigned int pause_time, u32 tx_cnt)
{
void __iomem *ioaddr = hw->pcsr;
- u32 v;
- v = readl(ioaddr + EMAC_RX_CTL0);
if (fc == FLOW_AUTO)
- v |= EMAC_RX_FLOW_CTL_EN;
+ setbits_le32(ioaddr + EMAC_RX_CTL0, EMAC_RX_FLOW_CTL_EN);
else
- v &= ~EMAC_RX_FLOW_CTL_EN;
- writel(v, ioaddr + EMAC_RX_CTL0);
-
- v = readl(ioaddr + EMAC_TX_FLOW_CTL);
+ clrbits_le32(ioaddr + EMAC_RX_CTL0, EMAC_RX_FLOW_CTL_EN);
if (fc == FLOW_AUTO)
- v |= EMAC_TX_FLOW_CTL_EN;
+ setbits_le32(ioaddr + EMAC_TX_FLOW_CTL, EMAC_TX_FLOW_CTL_EN);
else
- v &= ~EMAC_TX_FLOW_CTL_EN;
- writel(v, ioaddr + EMAC_TX_FLOW_CTL);
+ clrbits_le32(ioaddr + EMAC_TX_FLOW_CTL, EMAC_TX_FLOW_CTL_EN);
}
static int sun8i_dwmac_reset(struct stmmac_priv *priv)
--
2.18.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 6/7] drm: meson: use xxxsetbits_le32
This patch convert meson DRM driver to use all xxxsetbits_le32 functions.
Signed-off-by: Corentin Labbe
Reviewed-by: Neil Armstrong
Tested-by: Neil Armstrong
---
drivers/gpu/drm/meson/meson_crtc.c | 14 +++---
drivers/gpu/drm/meson/meson_dw_hdmi.c | 33 +++--
drivers/gpu/drm/meson/meson_plane.c | 13 ++---
drivers/gpu/drm/meson/meson_registers.h | 3 --
drivers/gpu/drm/meson/meson_venc.c | 13 ++---
drivers/gpu/drm/meson/meson_venc_cvbs.c | 4 +-
drivers/gpu/drm/meson/meson_viu.c | 65 +
drivers/gpu/drm/meson/meson_vpp.c | 22 -
8 files changed, 86 insertions(+), 81 deletions(-)
diff --git a/drivers/gpu/drm/meson/meson_crtc.c
b/drivers/gpu/drm/meson/meson_crtc.c
index 05520202c967..98f17ddd6b00 100644
--- a/drivers/gpu/drm/meson/meson_crtc.c
+++ b/drivers/gpu/drm/meson/meson_crtc.c
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -98,8 +99,8 @@ static void meson_crtc_atomic_enable(struct drm_crtc *crtc,
writel(crtc_state->mode.hdisplay,
priv->io_base + _REG(VPP_POSTBLEND_H_SIZE));
- writel_bits_relaxed(VPP_POSTBLEND_ENABLE, VPP_POSTBLEND_ENABLE,
- priv->io_base + _REG(VPP_MISC));
+ clrsetbits_le32_relaxed(priv->io_base + _REG(VPP_MISC),
+ VPP_POSTBLEND_ENABLE, VPP_POSTBLEND_ENABLE);
priv->viu.osd1_enabled = true;
}
@@ -114,8 +115,8 @@ static void meson_crtc_atomic_disable(struct drm_crtc *crtc,
priv->viu.osd1_commit = false;
/* Disable VPP Postblend */
- writel_bits_relaxed(VPP_POSTBLEND_ENABLE, 0,
- priv->io_base + _REG(VPP_MISC));
+ clrsetbits_le32_relaxed(priv->io_base + _REG(VPP_MISC),
+ VPP_POSTBLEND_ENABLE, 0);
if (crtc->state->event && !crtc->state->active) {
spin_lock_irq(>dev->event_lock);
@@ -199,8 +200,9 @@ void meson_crtc_irq(struct meson_drm *priv)
MESON_CANVAS_BLKMODE_LINEAR);
/* Enable OSD1 */
- writel_bits_relaxed(VPP_OSD1_POSTBLEND, VPP_OSD1_POSTBLEND,
- priv->io_base + _REG(VPP_MISC));
+ clrsetbits_le32_relaxed(priv->io_base + _REG(VPP_MISC),
+ VPP_OSD1_POSTBLEND,
+ VPP_OSD1_POSTBLEND);
priv->viu.osd1_commit = false;
}
diff --git a/drivers/gpu/drm/meson/meson_dw_hdmi.c
b/drivers/gpu/drm/meson/meson_dw_hdmi.c
index df7247cd93f9..99a136209e15 100644
--- a/drivers/gpu/drm/meson/meson_dw_hdmi.c
+++ b/drivers/gpu/drm/meson/meson_dw_hdmi.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#include
#include
@@ -427,10 +428,10 @@ static int dw_hdmi_phy_init(struct dw_hdmi *hdmi, void
*data,
writel_relaxed(0, priv->io_base + _REG(ENCP_VIDEO_EN));
/* Temporary Disable HDMI video stream to HDMI-TX */
- writel_bits_relaxed(0x3, 0,
- priv->io_base + _REG(VPU_HDMI_SETTING));
- writel_bits_relaxed(0xf << 8, 0,
- priv->io_base + _REG(VPU_HDMI_SETTING));
+ clrsetbits_le32_relaxed(priv->io_base + _REG(VPU_HDMI_SETTING), 0x3,
+ 0);
+ clrsetbits_le32_relaxed(priv->io_base + _REG(VPU_HDMI_SETTING),
+ 0xf << 8, 0);
/* Re-Enable VENC video stream */
if (priv->venc.hdmi_use_enci)
@@ -439,16 +440,16 @@ static int dw_hdmi_phy_init(struct dw_hdmi *hdmi, void
*data,
writel_relaxed(1, priv->io_base + _REG(ENCP_VIDEO_EN));
/* Push back HDMI clock settings */
- writel_bits_relaxed(0xf << 8, wr_clk & (0xf << 8),
- priv->io_base + _REG(VPU_HDMI_SETTING));
+ clrsetbits_le32_relaxed(priv->io_base + _REG(VPU_HDMI_SETTING),
+ 0xf << 8, wr_clk & (0xf << 8));
/* Enable and Select HDMI video source for HDMI-TX */
if (priv->venc.hdmi_use_enci)
- writel_bits_relaxed(0x3, MESON_VENC_SOURCE_ENCI,
- priv->io_base + _REG(VPU_HDMI_SETTING));
+ clrsetbits_le32_relaxed(priv->io_base + _REG(VPU_HDMI_SETTING),
+ 0x3, MESON_VENC_SOURCE_ENCI);
else
- writel_bits_relaxed(0x3, MESON_VENC_SOURCE_ENCP,
- priv->io_base + _REG(VPU_HDMI_SETTING));
+ clrsetbits_le32_relaxed(priv->io_base + _REG(VPU_HDMI_SETTING),
+ 0x3, MESON_VENC_SOURCE_ENCP);
return 0;
}
@@ -632,8 +633,8 @@ static void meson_venc_hdmi_encoder_disable(struct
drm_encoder *encoder)
DRM_DEBUG_DRIVER("\n");
- writel_bits_relaxed(0x3, 0,
- priv->io_base +
[RESEND PATCH 1/2] drm/panel: Add support for Armadeus ST0700 Adapt
This patch adds support for the Armadeus ST0700 Adapt. It comes with a
Santek ST0700I5Y-RBSLW 7.0" WVGA (800x480) TFT and an adapter board so
that it can be connected on the TFT header of Armadeus Dev boards.
Signed-off-by: Sébastien Szymanski
---
.../display/panel/armadeus,st0700-adapt.txt| 9 +++
drivers/gpu/drm/panel/panel-simple.c | 29 ++
2 files changed, 38 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/armadeus,st0700-adapt.txt
diff --git
a/Documentation/devicetree/bindings/display/panel/armadeus,st0700-adapt.txt
b/Documentation/devicetree/bindings/display/panel/armadeus,st0700-adapt.txt
new file mode 100644
index ..a30d63db3c8f
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/armadeus,st0700-adapt.txt
@@ -0,0 +1,9 @@
+Armadeus ST0700 Adapt. A Santek ST0700I5Y-RBSLW 7.0" WVGA (800x480) TFT with
+an adapter board.
+
+Required properties:
+- compatible: "armadeus,st0700-adapt"
+- power-supply: see panel-common.txt
+
+Optional properties:
+- backlight: see panel-common.txt
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 97964f7f2ace..e96df00a1c00 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -436,6 +436,32 @@ static const struct panel_desc ampire_am800480r3tmqwa1h = {
.bus_format = MEDIA_BUS_FMT_RGB666_1X18,
};
+static const struct display_timing santek_st0700i5y_rbslw_f_timing = {
+ .pixelclock = { 2640, 3330, 4680 },
+ .hactive = { 800, 800, 800 },
+ .hfront_porch = { 16, 210, 354 },
+ .hback_porch = { 45, 36, 6 },
+ .hsync_len = { 1, 10, 40 },
+ .vactive = { 480, 480, 480 },
+ .vfront_porch = { 7, 22, 147 },
+ .vback_porch = { 22, 13, 3 },
+ .vsync_len = { 1, 10, 20 },
+ .flags = DISPLAY_FLAGS_HSYNC_LOW | DISPLAY_FLAGS_VSYNC_LOW |
+ DISPLAY_FLAGS_DE_HIGH | DISPLAY_FLAGS_PIXDATA_POSEDGE
+};
+
+static const struct panel_desc armadeus_st0700_adapt = {
+ .timings = _st0700i5y_rbslw_f_timing,
+ .num_timings = 1,
+ .bpc = 6,
+ .size = {
+ .width = 154,
+ .height = 86,
+ },
+ .bus_format = MEDIA_BUS_FMT_RGB666_1X18,
+ .bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_POSEDGE,
+};
+
static const struct drm_display_mode auo_b101aw03_mode = {
.clock = 51450,
.hdisplay = 1024,
@@ -2330,6 +2356,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "ampire,am800480r3tmqwa1h",
.data = _am800480r3tmqwa1h,
+ }, {
+ .compatible = "armadeus,st0700-adapt",
+ .data = _st0700_adapt,
}, {
.compatible = "auo,b101aw03",
.data = _b101aw03,
--
2.16.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 1/7] powerpc: rename setbits32/clrbits32 to setbits_be32/clrbits_be32
Since setbits32/clrbits32 work on be32, it's better to remove ambiguity on
the used data type.
Signed-off-by: Corentin Labbe
---
arch/powerpc/include/asm/fsl_lbc.h| 2 +-
arch/powerpc/include/asm/io.h | 4 +-
arch/powerpc/platforms/44x/canyonlands.c | 4 +-
arch/powerpc/platforms/4xx/gpio.c | 28 +++
arch/powerpc/platforms/512x/pdm360ng.c| 6 +-
arch/powerpc/platforms/52xx/mpc52xx_common.c | 6 +-
arch/powerpc/platforms/52xx/mpc52xx_gpt.c | 12 +--
arch/powerpc/platforms/82xx/ep8248e.c | 2 +-
arch/powerpc/platforms/82xx/km82xx.c | 6 +-
arch/powerpc/platforms/82xx/mpc8272_ads.c | 10 +--
arch/powerpc/platforms/82xx/pq2.c | 2 +-
arch/powerpc/platforms/82xx/pq2ads-pci-pic.c | 4 +-
arch/powerpc/platforms/82xx/pq2fads.c | 10 +--
arch/powerpc/platforms/83xx/km83xx.c | 6 +-
arch/powerpc/platforms/83xx/mpc836x_mds.c | 2 +-
arch/powerpc/platforms/85xx/mpc85xx_mds.c | 2 +-
arch/powerpc/platforms/85xx/mpc85xx_pm_ops.c | 4 +-
arch/powerpc/platforms/85xx/mpc85xx_rdb.c | 2 +-
arch/powerpc/platforms/85xx/p1022_ds.c| 6 +-
arch/powerpc/platforms/85xx/p1022_rdk.c | 6 +-
arch/powerpc/platforms/85xx/t1042rdb_diu.c| 6 +-
arch/powerpc/platforms/85xx/twr_p102x.c | 2 +-
arch/powerpc/platforms/86xx/mpc8610_hpcd.c| 6 +-
arch/powerpc/platforms/8xx/adder875.c | 2 +-
arch/powerpc/platforms/8xx/m8xx_setup.c | 4 +-
arch/powerpc/platforms/8xx/mpc86xads_setup.c | 4 +-
arch/powerpc/platforms/8xx/mpc885ads_setup.c | 28 +++
.../platforms/embedded6xx/flipper-pic.c | 6 +-
arch/powerpc/platforms/embedded6xx/hlwd-pic.c | 8 +-
arch/powerpc/platforms/embedded6xx/wii.c | 12 +--
arch/powerpc/sysdev/cpm1.c| 26 +++
arch/powerpc/sysdev/cpm2.c| 16 ++--
arch/powerpc/sysdev/cpm_common.c | 4 +-
arch/powerpc/sysdev/fsl_85xx_l2ctlr.c | 16 ++--
arch/powerpc/sysdev/fsl_lbc.c | 2 +-
arch/powerpc/sysdev/fsl_pci.c | 12 +--
arch/powerpc/sysdev/fsl_pmc.c | 2 +-
arch/powerpc/sysdev/fsl_rcpm.c| 74 +--
arch/powerpc/sysdev/fsl_rio.c | 4 +-
arch/powerpc/sysdev/fsl_rmu.c | 9 ++-
arch/powerpc/sysdev/mpic_timer.c | 12 +--
41 files changed, 190 insertions(+), 189 deletions(-)
diff --git a/arch/powerpc/include/asm/fsl_lbc.h
b/arch/powerpc/include/asm/fsl_lbc.h
index c7240a024b96..4d6a56b48a28 100644
--- a/arch/powerpc/include/asm/fsl_lbc.h
+++ b/arch/powerpc/include/asm/fsl_lbc.h
@@ -276,7 +276,7 @@ static inline void fsl_upm_start_pattern(struct fsl_upm
*upm, u8 pat_offset)
*/
static inline void fsl_upm_end_pattern(struct fsl_upm *upm)
{
- clrbits32(upm->mxmr, MxMR_OP_RP);
+ clrbits_be32(upm->mxmr, MxMR_OP_RP);
while (in_be32(upm->mxmr) & MxMR_OP_RP)
cpu_relax();
diff --git a/arch/powerpc/include/asm/io.h b/arch/powerpc/include/asm/io.h
index 0a034519957d..bc2fc014fd4f 100644
--- a/arch/powerpc/include/asm/io.h
+++ b/arch/powerpc/include/asm/io.h
@@ -882,8 +882,8 @@ static inline void * bus_to_virt(unsigned long address)
#endif /* CONFIG_PPC32 */
/* access ports */
-#define setbits32(_addr, _v) out_be32((_addr), in_be32(_addr) | (_v))
-#define clrbits32(_addr, _v) out_be32((_addr), in_be32(_addr) & ~(_v))
+#define setbits_be32(_addr, _v) out_be32((_addr), in_be32(_addr) | (_v))
+#define clrbits_be32(_addr, _v) out_be32((_addr), in_be32(_addr) & ~(_v))
#define setbits16(_addr, _v) out_be16((_addr), in_be16(_addr) | (_v))
#define clrbits16(_addr, _v) out_be16((_addr), in_be16(_addr) & ~(_v))
diff --git a/arch/powerpc/platforms/44x/canyonlands.c
b/arch/powerpc/platforms/44x/canyonlands.c
index 157f4ce46386..6aeb4ca64d09 100644
--- a/arch/powerpc/platforms/44x/canyonlands.c
+++ b/arch/powerpc/platforms/44x/canyonlands.c
@@ -113,8 +113,8 @@ static int __init ppc460ex_canyonlands_fixup(void)
* USB2HStop and gpio19 will be USB2DStop. For more details refer to
* table 34-7 of PPC460EX user manual.
*/
- setbits32((vaddr + GPIO0_OSRH), 0x4200);
- setbits32((vaddr + GPIO0_TSRH), 0x4200);
+ setbits_be32((vaddr + GPIO0_OSRH), 0x4200);
+ setbits_be32((vaddr + GPIO0_TSRH), 0x4200);
err_gpio:
iounmap(vaddr);
err_bcsr:
diff --git a/arch/powerpc/platforms/4xx/gpio.c
b/arch/powerpc/platforms/4xx/gpio.c
index 2238e369cde4..8436da0617fd 100644
--- a/arch/powerpc/platforms/4xx/gpio.c
+++ b/arch/powerpc/platforms/4xx/gpio.c
@@ -82,9 +82,9 @@ __ppc4xx_gpio_set(struct gpio_chip *gc, unsigned int gpio,
int val)
struct ppc4xx_gpio __iomem *regs = mm_gc->regs;
if (val)
- setbits32(>or, GPIO_MASK(gpio));
+ setbits_be32(>or, GPIO_MASK(gpio));
else
- clrbits32(>or,
[RESEND PATCH 2/2] ARM: dts: opos6uldev: use OF graph to describe the display
To make use of the new eLCDIF DRM driver OF graph description is
required. Describe the display using OF graph nodes.
Signed-off-by: Sébastien Szymanski
---
arch/arm/boot/dts/imx6ul-opos6uldev.dts | 37 ++---
1 file changed, 16 insertions(+), 21 deletions(-)
diff --git a/arch/arm/boot/dts/imx6ul-opos6uldev.dts
b/arch/arm/boot/dts/imx6ul-opos6uldev.dts
index 0e59ee57fd55..8ecdb9ad2b2e 100644
--- a/arch/arm/boot/dts/imx6ul-opos6uldev.dts
+++ b/arch/arm/boot/dts/imx6ul-opos6uldev.dts
@@ -56,7 +56,7 @@
stdout-path =
};
- backlight {
+ backlight: backlight {
compatible = "pwm-backlight";
pwms = < 0 191000>;
brightness-levels = <0 4 8 16 32 64 128 255>;
@@ -97,6 +97,18 @@
gpios = < 1 GPIO_ACTIVE_HIGH>;
};
+ panel: panel {
+ compatible = "armadeus,st0700-adapt";
+ power-supply = <_3v3>;
+ backlight = <>;
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <_out>;
+ };
+ };
+ };
+
reg_5v: regulator-5v {
compatible = "regulator-fixed";
regulator-name = "5V";
@@ -182,28 +194,11 @@
{
pinctrl-names = "default";
pinctrl-0 = <_lcdif>;
- display = <>;
- lcd-supply = <_3v3>;
status = "okay";
- display0: display0 {
- bits-per-pixel = <32>;
- bus-width = <18>;
-
- display-timings {
- timing0: timing0 {
- clock-frequency = <3333>;
- hactive = <800>;
- vactive = <480>;
- hback-porch = <96>;
- hfront-porch = <96>;
- vback-porch = <20>;
- vfront-porch = <21>;
- hsync-len = <64>;
- vsync-len = <4>;
- de-active = <1>;
- pixelclk-active = <0>;
- };
+ port {
+ lcdif_out: endpoint {
+ remote-endpoint = <_in>;
};
};
};
--
2.16.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 7/7] net: stmmac: dwmac-meson8b: use xxxsetbits_le32
This patch convert meson stmmac glue driver to use all xxxsetbits_le32
functions.
Signed-off-by: Corentin Labbe
Reviewed-by: Neil Armstrong
---
.../ethernet/stmicro/stmmac/dwmac-meson8b.c | 56 ---
1 file changed, 22 insertions(+), 34 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
b/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
index c5979569fd60..abcf65588576 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#include "stmmac_platform.h"
@@ -75,18 +76,6 @@ struct meson8b_dwmac_clk_configs {
struct clk_gate rgmii_tx_en;
};
-static void meson8b_dwmac_mask_bits(struct meson8b_dwmac *dwmac, u32 reg,
- u32 mask, u32 value)
-{
- u32 data;
-
- data = readl(dwmac->regs + reg);
- data &= ~mask;
- data |= (value & mask);
-
- writel(data, dwmac->regs + reg);
-}
-
static struct clk *meson8b_dwmac_register_clk(struct meson8b_dwmac *dwmac,
const char *name_suffix,
const char **parent_names,
@@ -192,14 +181,13 @@ static int meson8b_set_phy_mode(struct meson8b_dwmac
*dwmac)
case PHY_INTERFACE_MODE_RGMII_ID:
case PHY_INTERFACE_MODE_RGMII_TXID:
/* enable RGMII mode */
- meson8b_dwmac_mask_bits(dwmac, PRG_ETH0,
- PRG_ETH0_RGMII_MODE,
- PRG_ETH0_RGMII_MODE);
+ clrsetbits_le32(dwmac->regs + PRG_ETH0, PRG_ETH0_RGMII_MODE,
+ PRG_ETH0_RGMII_MODE);
break;
case PHY_INTERFACE_MODE_RMII:
/* disable RGMII mode -> enables RMII mode */
- meson8b_dwmac_mask_bits(dwmac, PRG_ETH0,
- PRG_ETH0_RGMII_MODE, 0);
+ clrsetbits_le32(dwmac->regs + PRG_ETH0, PRG_ETH0_RGMII_MODE,
+ 0);
break;
default:
dev_err(dwmac->dev, "fail to set phy-mode %s\n",
@@ -218,15 +206,15 @@ static int meson_axg_set_phy_mode(struct meson8b_dwmac
*dwmac)
case PHY_INTERFACE_MODE_RGMII_ID:
case PHY_INTERFACE_MODE_RGMII_TXID:
/* enable RGMII mode */
- meson8b_dwmac_mask_bits(dwmac, PRG_ETH0,
- PRG_ETH0_EXT_PHY_MODE_MASK,
- PRG_ETH0_EXT_RGMII_MODE);
+ clrsetbits_le32(dwmac->regs + PRG_ETH0,
+ PRG_ETH0_EXT_PHY_MODE_MASK,
+ PRG_ETH0_EXT_RGMII_MODE);
break;
case PHY_INTERFACE_MODE_RMII:
/* disable RGMII mode -> enables RMII mode */
- meson8b_dwmac_mask_bits(dwmac, PRG_ETH0,
- PRG_ETH0_EXT_PHY_MODE_MASK,
- PRG_ETH0_EXT_RMII_MODE);
+ clrsetbits_le32(dwmac->regs + PRG_ETH0,
+ PRG_ETH0_EXT_PHY_MODE_MASK,
+ PRG_ETH0_EXT_RMII_MODE);
break;
default:
dev_err(dwmac->dev, "fail to set phy-mode %s\n",
@@ -255,11 +243,11 @@ static int meson8b_init_prg_eth(struct meson8b_dwmac
*dwmac)
case PHY_INTERFACE_MODE_RGMII_ID:
case PHY_INTERFACE_MODE_RGMII_TXID:
/* only relevant for RMII mode -> disable in RGMII mode */
- meson8b_dwmac_mask_bits(dwmac, PRG_ETH0,
- PRG_ETH0_INVERTED_RMII_CLK, 0);
+ clrsetbits_le32(dwmac->regs + PRG_ETH0,
+ PRG_ETH0_INVERTED_RMII_CLK, 0);
- meson8b_dwmac_mask_bits(dwmac, PRG_ETH0, PRG_ETH0_TXDLY_MASK,
- tx_dly_val << PRG_ETH0_TXDLY_SHIFT);
+ clrsetbits_le32(dwmac->regs + PRG_ETH0, PRG_ETH0_TXDLY_MASK,
+ tx_dly_val << PRG_ETH0_TXDLY_SHIFT);
/* Configure the 125MHz RGMII TX clock, the IP block changes
* the output automatically (= without us having to configure
@@ -287,13 +275,13 @@ static int meson8b_init_prg_eth(struct meson8b_dwmac
*dwmac)
case PHY_INTERFACE_MODE_RMII:
/* invert internal clk_rmii_i to generate 25/2.5 tx_rx_clk */
- meson8b_dwmac_mask_bits(dwmac, PRG_ETH0,
- PRG_ETH0_INVERTED_RMII_CLK,
- PRG_ETH0_INVERTED_RMII_CLK);
+ clrsetbits_le32(dwmac->regs + PRG_ETH0,
+ PRG_ETH0_INVERTED_RMII_CLK,
+ PRG_ETH0_INVERTED_RMII_CLK);
/* TX clock delay cannot be
[PATCH v3 2/7] include: add setbits_leXX/clrbits_leXX/clrsetbits_leXX in linux/setbits.h
This patch adds setbits_le32/clrbits_le32/clrsetbits_le32 and setbits_le64/clrbits_le64/clrsetbits_le64 in linux/setbits.h header. Signed-off-by: Corentin Labbe --- include/linux/setbits.h | 84 + 1 file changed, 84 insertions(+) create mode 100644 include/linux/setbits.h diff --git a/include/linux/setbits.h b/include/linux/setbits.h new file mode 100644 index ..c82faf8d7fe4 --- /dev/null +++ b/include/linux/setbits.h @@ -0,0 +1,84 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +#ifndef __LINUX_SETBITS_H +#define __LINUX_SETBITS_H + +#include + +#define __setbits(rfn, wfn, addr, set) wfn((rfn(addr) | (set)), addr) +#define __clrbits(rfn, wfn, addr, mask) wfn((rfn(addr) & ~(mask)), addr) +#define __clrsetbits(rfn, wfn, addr, mask, set) wfn(((rfn(addr) & ~(mask)) | (set)), addr) +#define __setclrbits(rfn, wfn, addr, mask, set) wfn(((rfn(addr) | (set)) & ~(mask)), addr) + +#ifndef setbits_le32 +#define setbits_le32(addr, set) __setbits(readl, writel, addr, set) +#endif +#ifndef setbits_le32_relaxed +#define setbits_le32_relaxed(addr, set) __setbits(readl_relaxed, writel_relaxed, \ + addr, set) +#endif + +#ifndef clrbits_le32 +#define clrbits_le32(addr, mask) __clrbits(readl, writel, addr, mask) +#endif +#ifndef clrbits_le32_relaxed +#define clrbits_le32_relaxed(addr, mask) __clrbits(readl_relaxed, writel_relaxed, \ + addr, mask) +#endif + +#ifndef clrsetbits_le32 +#define clrsetbits_le32(addr, mask, set) __clrsetbits(readl, writel, addr, mask, set) +#endif +#ifndef clrsetbits_le32_relaxed +#define clrsetbits_le32_relaxed(addr, mask, set) __clrsetbits(readl_relaxed, \ + writel_relaxed, \ + addr, mask, set) +#endif + +#ifndef setclrbits_le32 +#define setclrbits_le32(addr, mask, set) __setclrbits(readl, writel, addr, mask, set) +#endif +#ifndef setclrbits_le32_relaxed +#define setclrbits_le32_relaxed(addr, mask, set) __setclrbits(readl_relaxed, \ + writel_relaxed, \ + addr, mask, set) +#endif + +/* We cannot use CONFIG_64BIT as some x86 drivers use non-atomicwriteq() */ +#if defined(writeq) && defined(readq) +#ifndef setbits_le64 +#define setbits_le64(addr, set) __setbits(readq, writeq, addr, set) +#endif +#ifndef setbits_le64_relaxed +#define setbits_le64_relaxed(addr, set) __setbits(readq_relaxed, writeq_relaxed, \ + addr, set) +#endif + +#ifndef clrbits_le64 +#define clrbits_le64(addr, mask) __clrbits(readq, writeq, addr, mask) +#endif +#ifndef clrbits_le64_relaxed +#define clrbits_le64_relaxed(addr, mask) __clrbits(readq_relaxed, writeq_relaxed, \ + addr, mask) +#endif + +#ifndef clrsetbits_le64 +#define clrsetbits_le64(addr, mask, set) __clrsetbits(readq, writeq, addr, mask, set) +#endif +#ifndef clrsetbits_le64_relaxed +#define clrsetbits_le64_relaxed(addr, mask, set) __clrsetbits(readq_relaxed, \ + writeq_relaxed, \ + addr, mask, set) +#endif + +#ifndef setclrbits_le64 +#define setclrbits_le64(addr, mask, set) __setclrbits(readq, writeq, addr, mask, set) +#endif +#ifndef setclrbits_le64_relaxed +#define setclrbits_le64_relaxed(addr, mask, set) __setclrbits(readq_relaxed, \ + writeq_relaxed, \ + addr, mask, set) +#endif + +#endif /* writeq/readq */ + +#endif /* __LINUX_SETBITS_H */ -- 2.18.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 4/7] ata: ahci_sunxi: use xxxsetbitsi_le32 functions
This patch converts ahci_sunxi to use xxxsetbits_le32 functions
Signed-off-by: Corentin Labbe
---
drivers/ata/ahci_sunxi.c | 62 +++-
1 file changed, 17 insertions(+), 45 deletions(-)
diff --git a/drivers/ata/ahci_sunxi.c b/drivers/ata/ahci_sunxi.c
index 911710643305..69c2e01c3d52 100644
--- a/drivers/ata/ahci_sunxi.c
+++ b/drivers/ata/ahci_sunxi.c
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
#include "ahci.h"
#define DRV_NAME "ahci-sunxi"
@@ -58,34 +59,6 @@ MODULE_PARM_DESC(enable_pmp,
#define AHCI_P0PHYCR 0x0178
#define AHCI_P0PHYSR 0x017c
-static void sunxi_clrbits(void __iomem *reg, u32 clr_val)
-{
- u32 reg_val;
-
- reg_val = readl(reg);
- reg_val &= ~(clr_val);
- writel(reg_val, reg);
-}
-
-static void sunxi_setbits(void __iomem *reg, u32 set_val)
-{
- u32 reg_val;
-
- reg_val = readl(reg);
- reg_val |= set_val;
- writel(reg_val, reg);
-}
-
-static void sunxi_clrsetbits(void __iomem *reg, u32 clr_val, u32 set_val)
-{
- u32 reg_val;
-
- reg_val = readl(reg);
- reg_val &= ~(clr_val);
- reg_val |= set_val;
- writel(reg_val, reg);
-}
-
static u32 sunxi_getbits(void __iomem *reg, u8 mask, u8 shift)
{
return (readl(reg) >> shift) & mask;
@@ -100,22 +73,21 @@ static int ahci_sunxi_phy_init(struct device *dev, void
__iomem *reg_base)
writel(0, reg_base + AHCI_RWCR);
msleep(5);
- sunxi_setbits(reg_base + AHCI_PHYCS1R, BIT(19));
- sunxi_clrsetbits(reg_base + AHCI_PHYCS0R,
-(0x7 << 24),
-(0x5 << 24) | BIT(23) | BIT(18));
- sunxi_clrsetbits(reg_base + AHCI_PHYCS1R,
-(0x3 << 16) | (0x1f << 8) | (0x3 << 6),
-(0x2 << 16) | (0x6 << 8) | (0x2 << 6));
- sunxi_setbits(reg_base + AHCI_PHYCS1R, BIT(28) | BIT(15));
- sunxi_clrbits(reg_base + AHCI_PHYCS1R, BIT(19));
- sunxi_clrsetbits(reg_base + AHCI_PHYCS0R,
-(0x7 << 20), (0x3 << 20));
- sunxi_clrsetbits(reg_base + AHCI_PHYCS2R,
-(0x1f << 5), (0x19 << 5));
+ setbits_le32(reg_base + AHCI_PHYCS1R, BIT(19));
+ clrsetbits_le32(reg_base + AHCI_PHYCS0R, (0x7 << 24),
+ (0x5 << 24) | BIT(23) | BIT(18));
+ clrsetbits_le32(reg_base + AHCI_PHYCS1R,
+ (0x3 << 16) | (0x1f << 8) | (0x3 << 6),
+ (0x2 << 16) | (0x6 << 8) | (0x2 << 6));
+ setbits_le32(reg_base + AHCI_PHYCS1R, BIT(28) | BIT(15));
+ clrbits_le32(reg_base + AHCI_PHYCS1R, BIT(19));
+ clrsetbits_le32(reg_base + AHCI_PHYCS0R,
+ (0x7 << 20), (0x3 << 20));
+ clrsetbits_le32(reg_base + AHCI_PHYCS2R,
+ (0x1f << 5), (0x19 << 5));
msleep(5);
- sunxi_setbits(reg_base + AHCI_PHYCS0R, (0x1 << 19));
+ setbits_le32(reg_base + AHCI_PHYCS0R, (0x1 << 19));
timeout = 250; /* Power up takes aprox 50 us */
do {
@@ -130,7 +102,7 @@ static int ahci_sunxi_phy_init(struct device *dev, void
__iomem *reg_base)
udelay(1);
} while (1);
- sunxi_setbits(reg_base + AHCI_PHYCS2R, (0x1 << 24));
+ setbits_le32(reg_base + AHCI_PHYCS2R, (0x1 << 24));
timeout = 100; /* Calibration takes aprox 10 us */
do {
@@ -158,10 +130,10 @@ static void ahci_sunxi_start_engine(struct ata_port *ap)
struct ahci_host_priv *hpriv = ap->host->private_data;
/* Setup DMA before DMA start */
- sunxi_clrsetbits(hpriv->mmio + AHCI_P0DMACR, 0xff00, 0x4400);
+ clrsetbits_le32(hpriv->mmio + AHCI_P0DMACR, 0xff00, 0x4400);
/* Start DMA */
- sunxi_setbits(port_mmio + PORT_CMD, PORT_CMD_START);
+ setbits_le32(port_mmio + PORT_CMD, PORT_CMD_START);
}
static const struct ata_port_info ahci_sunxi_port_info = {
--
2.18.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: fix call_kern.cocci warnings (fwd)
Am 25.10.18 um 03:28 schrieb Zhou, David(ChunMing):
Reviewed-by: Chunming Zhou
NAK, GFP_ATOMIC should be avoided.
The correct solution is to move the allocation out of the spinlock or
drop the lock and reacquire.
Christian.
-Original Message-
From: Julia Lawall
Sent: Thursday, October 25, 2018 2:57 AM
To: Zhou, David(ChunMing)
Cc: kbuild-...@01.org; intel-...@lists.freedesktop.org; dri-
de...@lists.freedesktop.org; Christian König
; Gustavo Padovan
; Maarten Lankhorst
; Sean Paul ; David
Airlie ; dri-devel@lists.freedesktop.org; linux-
ker...@vger.kernel.org
Subject: [PATCH] drm: fix call_kern.cocci warnings (fwd)
The containing function is called with a spin_lock held, so GFP_KERNEL can't
be used.
julia
-- Forwarded message --
Date: Tue, 23 Oct 2018 17:14:25 +0800
From: kbuild test robot
To: kbu...@01.org
Cc: Julia Lawall
Subject: [PATCH] drm: fix call_kern.cocci warnings
CC: kbuild-...@01.org
CC: intel-...@lists.freedesktop.org
CC: dri-devel@lists.freedesktop.org
TO: Chunming Zhou
CC: "Christian König"
CC: Gustavo Padovan
CC: Maarten Lankhorst
CC: Sean Paul
CC: David Airlie
CC: dri-devel@lists.freedesktop.org
CC: linux-ker...@vger.kernel.org
From: kbuild test robot
drivers/gpu/drm/drm_syncobj.c:202:4-14: ERROR: function
drm_syncobj_find_signal_pt_for_point called on line 390 inside lock on line
389 but uses GFP_KERNEL
Find functions that refer to GFP_KERNEL but are called with locks held.
Semantic patch information:
The proposed change of converting the GFP_KERNEL is not necessarily the
correct one. It may be desired to unlock the lock, or to not call the function
under the lock in the first place.
Generated by: scripts/coccinelle/locks/call_kern.cocci
Fixes: 48197bc564c7 ("drm: add syncobj timeline support v9")
CC: Chunming Zhou
Signed-off-by: kbuild test robot
---
tree: git://anongit.freedesktop.org/drm/drm-tip drm-tip
head: 8d7ffd2298c607c3e1a16f94d51450d7940fd6a7
commit: 48197bc564c7a1888c86024a1ba4f956e0ec2300 [1968/2033] drm: add
syncobj timeline support v9
:: branch date: 4 hours ago
:: commit date: 5 days ago
Please take the patch only if it's a positive warning. Thanks!
drm_syncobj.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -199,7 +199,7 @@ static struct dma_fence
(point <= syncobj->timeline)) {
struct drm_syncobj_stub_fence *fence =
kzalloc(sizeof(struct drm_syncobj_stub_fence),
- GFP_KERNEL);
+ GFP_ATOMIC);
if (!fence)
return NULL;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v10 2/2] drm/i915: Adding YUV444 packed format support for skl+
Op 24-10-18 om 19:17 schreef Matt Roper:
> On Tue, Oct 23, 2018 at 01:39:10PM +0200, Maarten Lankhorst wrote:
>>
>> Op 02-10-18 om 13:15 schreef Stanislav Lisovskiy:
>>> PLANE_CTL_FORMAT_AYUV is already supported, according to hardware
>>> specification.
>>>
>>> v2: Edited commit message, removed redundant whitespaces.
>>>
>>> v3: Fixed fallthrough logic for the format switch cases.
>>>
>>> v4: Yet again fixed fallthrough logic, to reuse code from other case
>>> labels.
>>>
>>> v5: Started to use XYUV instead of AYUV, as we don't use alpha.
>>>
>>> v6: Removed unneeded initializer for new XYUV format.
>>>
>>> v7: Added scaling support for DRM_FORMAT_XYUV
>>>
>>> v8: Edited commit message to be more clear about skl+, renamed
>>> PLANE_CTL_FORMAT_AYUV to PLANE_CTL_FORMAT_XYUV as this format
>>> doesn't support per-pixel alpha. Fixed minor code issues.
>>>
>>> v9: Moved DRM format check to proper place in intel_framebuffer_init.
>>>
>>> v10: Added missing XYUV format to sprite planes for skl+.
>>>
>>> Signed-off-by: Stanislav Lisovskiy
>>> ---
>>> drivers/gpu/drm/i915/i915_reg.h | 2 +-
>>> drivers/gpu/drm/i915/intel_display.c | 15 +++
>>> drivers/gpu/drm/i915/intel_sprite.c | 3 +++
>>> 3 files changed, 19 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/i915_reg.h
>>> b/drivers/gpu/drm/i915/i915_reg.h
>>> index 09bc8e730ee1..ac24ac4b1d51 100644
>>> --- a/drivers/gpu/drm/i915/i915_reg.h
>>> +++ b/drivers/gpu/drm/i915/i915_reg.h
>>> @@ -6501,7 +6501,7 @@ enum {
>>> #define PLANE_CTL_FORMAT_XRGB_2101010(2 << 24)
>>> #define PLANE_CTL_FORMAT_XRGB_ (4 << 24)
>>> #define PLANE_CTL_FORMAT_XRGB_16161616F (6 << 24)
>>> -#define PLANE_CTL_FORMAT_AYUV(8 << 24)
>>> +#define PLANE_CTL_FORMAT_XYUV(8 << 24)
>> It's the same format as AYUV, don't add a separate definition here for it.
>> The only difference is we ignore the alpha channel.
> I think he's just renaming the format that's already been added to be
> more consistent with how we name our other PLANE_CTL_FORMAT_
> definitions. I.e., all the rgb types use "XRGB" in the name.
>
Ah k, with your explanation it makes more sense then. :)
Yeah just zap the AYUV if there's no alpha channel.
~Maarten
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108521] RX 580 as eGPU amdgpu: gpu post error!
https://bugs.freedesktop.org/show_bug.cgi?id=108521 Christian König changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |NOTOURBUG --- Comment #13 from Christian König --- This problem isn't related to the GPU in any way, that the amdgpu driver fails to load is just another symptom. The Thunderbolt bridge doesn't get enough resources assigned for its devices even when the GPU isn't present at all for some reason. That could be a problem with the BIOS, with the Linux Thunderbolt or the resource allocation in the PCI subsystem. Please provide the output of "sudo cat /proc/iomem" and "lspci -t -nn -v" together with an up to date dmesg. -- 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 3/4] drm/i915: wrapping all hdcp var into intel_hdcp
Considering significant number of HDCP specific variables, it will
be clean to have separate struct for HDCP.
New structure called intel_hdcp is added within intel_connector.
v2:
struct hdcp statically allocated. [Sean Paul]
enable and disable function parameters are retained.[Sean Paul]
v3:
No Changes.
v4:
Commit msg is rephrased [Uma]
v5:
Comment for mutex definition.
v6:
hdcp_ prefix from all intel_hdcp members are removed [Sean Paul]
inline function intel_hdcp_to_connector is defined [Sean Paul]
v7:
%s/uint64_t/u64
v8:
Rebased
Signed-off-by: Ramalingam C
Reviewed-by: Sean Paul
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
drivers/gpu/drm/i915/intel_display.c | 6 +-
drivers/gpu/drm/i915/intel_drv.h | 15 +++--
drivers/gpu/drm/i915/intel_hdcp.c| 109 +++
4 files changed, 74 insertions(+), 58 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 5cadfcd03ea9..041319d48ca3 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4986,7 +4986,7 @@ static int i915_hdcp_sink_capability_show(struct seq_file
*m, void *data)
return -ENODEV;
/* HDCP is supported by connector */
- if (!intel_connector->hdcp_shim)
+ if (!intel_connector->hdcp.shim)
return -EINVAL;
seq_printf(m, "%s:%d HDCP version: ", connector->name,
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index fe045abb6472..0aabc4b9854a 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -15776,9 +15776,9 @@ static void intel_hpd_poll_fini(struct drm_device *dev)
for_each_intel_connector_iter(connector, _iter) {
if (connector->modeset_retry_work.func)
cancel_work_sync(>modeset_retry_work);
- if (connector->hdcp_shim) {
- cancel_delayed_work_sync(>hdcp_check_work);
- cancel_work_sync(>hdcp_prop_work);
+ if (connector->hdcp.shim) {
+ cancel_delayed_work_sync(>hdcp.check_work);
+ cancel_work_sync(>hdcp.prop_work);
}
}
drm_connector_list_iter_end(_iter);
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index db24308729b4..268afb6d2746 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -381,6 +381,15 @@ struct intel_hdcp_shim {
bool *hdcp_capable);
};
+struct intel_hdcp {
+ const struct intel_hdcp_shim *shim;
+ /* Mutex for hdcp state of the connector */
+ struct mutex mutex;
+ u64 value;
+ struct delayed_work check_work;
+ struct work_struct prop_work;
+};
+
struct intel_connector {
struct drm_connector base;
/*
@@ -413,11 +422,7 @@ struct intel_connector {
/* Work struct to schedule a uevent on link train failure */
struct work_struct modeset_retry_work;
- const struct intel_hdcp_shim *hdcp_shim;
- struct mutex hdcp_mutex;
- uint64_t hdcp_value; /* protected by hdcp_mutex */
- struct delayed_work hdcp_check_work;
- struct work_struct hdcp_prop_work;
+ struct intel_hdcp hdcp;
};
struct intel_digital_connector_state {
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
b/drivers/gpu/drm/i915/intel_hdcp.c
index 5b423a78518d..26daf54ffde9 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -55,7 +55,7 @@ int intel_hdcp_read_valid_bksv(struct intel_digital_port
*intel_dig_port,
bool intel_hdcp_capable(struct intel_connector *connector)
{
struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
- const struct intel_hdcp_shim *shim = connector->hdcp_shim;
+ const struct intel_hdcp_shim *shim = connector->hdcp.shim;
bool capable = false;
u8 bksv[5];
@@ -655,6 +655,7 @@ static int intel_hdcp_auth(struct intel_digital_port
*intel_dig_port,
static int _intel_hdcp_disable(struct intel_connector *connector)
{
+ struct intel_hdcp *hdcp = >hdcp;
struct drm_i915_private *dev_priv = connector->base.dev->dev_private;
struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
enum port port = intel_dig_port->base.port;
@@ -670,7 +671,7 @@ static int _intel_hdcp_disable(struct intel_connector
*connector)
return -ETIMEDOUT;
}
- ret = connector->hdcp_shim->toggle_signalling(intel_dig_port, false);
+ ret = hdcp->shim->toggle_signalling(intel_dig_port, false);
if (ret) {
DRM_ERROR("Failed to disable HDCP signalling\n");
return ret;
@@ -682,6 +683,7 @@ static int _intel_hdcp_disable(struct intel_connector
*connector)
static int
[PATCH 1/4] drm: hdcp2.2 authentication msg definitions
This patch defines the hdcp2.2 protocol messages for authentication.
v2:
bit_fields are removed. Instead bitmasking used. [Tomas and Jani]
prefix HDCP_2_2_ is added to the macros. [Tomas]
v3:
No Changes.
v4:
Style and spellings are fixed [Uma]
v5:
Fix for macros.
v6:
comment for Type is improved [Sean Paul]
v7:
%s/HDCP_2_2_LPRIME_HALF_LEN/HDCP_2_2_V_PRIME_HALF_LEN [Uma]
%s/uintxx_t/uxx
v8:
%s/eceiver_id/receiver_id
Signed-off-by: Ramalingam C
Reviewed-by: Uma Shankar
---
include/drm/drm_hdcp.h | 184 +
1 file changed, 184 insertions(+)
diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h
index 98e63d870139..7cd7269c7c7b 100644
--- a/include/drm/drm_hdcp.h
+++ b/include/drm/drm_hdcp.h
@@ -38,4 +38,188 @@
#define DRM_HDCP_DDC_BSTATUS 0x41
#define DRM_HDCP_DDC_KSV_FIFO 0x43
+#define DRM_HDCP_1_4_SRM_ID0x8
+#define DRM_HDCP_1_4_VRL_LENGTH_SIZE 3
+#define DRM_HDCP_1_4_DCP_SIG_SIZE 40
+
+/* Protocol message definition for HDCP2.2 specification */
+/*
+ * Protected content streams are classified into 2 types:
+ * - Type0: Can be transmitted with HDCP 1.4+
+ * - Type1: Can be transmitted with HDCP 2.2+
+ */
+#define HDCP_STREAM_TYPE0 0x00
+#define HDCP_STREAM_TYPE1 0x01
+
+/* HDCP2.2 Msg IDs */
+#define HDCP_2_2_NULL_MSG 1
+#define HDCP_2_2_AKE_INIT 2
+#define HDCP_2_2_AKE_SEND_CERT 3
+#define HDCP_2_2_AKE_NO_STORED_KM 4
+#define HDCP_2_2_AKE_STORED_KM 5
+#define HDCP_2_2_AKE_SEND_HPRIME 7
+#define HDCP_2_2_AKE_SEND_PAIRING_INFO 8
+#define HDCP_2_2_LC_INIT 9
+#define HDCP_2_2_LC_SEND_LPRIME10
+#define HDCP_2_2_SKE_SEND_EKS 11
+#define HDCP_2_2_REP_SEND_RECVID_LIST 12
+#define HDCP_2_2_REP_SEND_ACK 15
+#define HDCP_2_2_REP_STREAM_MANAGE 16
+#define HDCP_2_2_REP_STREAM_READY 17
+#define HDCP_2_2_ERRATA_DP_STREAM_TYPE 50
+
+#define HDCP_2_2_RTX_LEN 8
+#define HDCP_2_2_RRX_LEN 8
+
+#define HDCP_2_2_K_PUB_RX_MOD_N_LEN128
+#define HDCP_2_2_K_PUB_RX_EXP_E_LEN3
+#define HDCP_2_2_K_PUB_RX_LEN (HDCP_2_2_K_PUB_RX_MOD_N_LEN + \
+HDCP_2_2_K_PUB_RX_EXP_E_LEN)
+
+#define HDCP_2_2_DCP_LLC_SIG_LEN 384
+
+#define HDCP_2_2_E_KPUB_KM_LEN 128
+#define HDCP_2_2_E_KH_KM_M_LEN (16 + 16)
+#define HDCP_2_2_H_PRIME_LEN 32
+#define HDCP_2_2_E_KH_KM_LEN 16
+#define HDCP_2_2_RN_LEN8
+#define HDCP_2_2_L_PRIME_LEN 32
+#define HDCP_2_2_E_DKEY_KS_LEN 16
+#define HDCP_2_2_RIV_LEN 8
+#define HDCP_2_2_SEQ_NUM_LEN 3
+#define HDCP_2_2_V_PRIME_HALF_LEN (HDCP_2_2_L_PRIME_LEN / 2)
+#define HDCP_2_2_RECEIVER_ID_LEN DRM_HDCP_KSV_LEN
+#define HDCP_2_2_MAX_DEVICE_COUNT 31
+#define HDCP_2_2_RECEIVER_IDS_MAX_LEN (HDCP_2_2_RECEIVER_ID_LEN * \
+HDCP_2_2_MAX_DEVICE_COUNT)
+#define HDCP_2_2_MPRIME_LEN32
+
+/* Following Macros take a byte at a time for bit(s) masking */
+/*
+ * TODO: This has to be changed for DP MST, as multiple stream on
+ * same port is possible.
+ * For HDCP2.2 on HDMI and DP SST this value is always 1.
+ */
+#define HDCP_2_2_MAX_CONTENT_STREAMS_CNT 1
+#define HDCP_2_2_TXCAP_MASK_LEN2
+#define HDCP_2_2_RXCAPS_LEN3
+#define HDCP_2_2_RX_REPEATER(x)((x) & BIT(0))
+#define HDCP_2_2_DP_HDCP_CAPABLE(x)((x) & BIT(1))
+#define HDCP_2_2_RXINFO_LEN2
+
+/* HDCP1.x compliant device in downstream */
+#define HDCP_2_2_HDCP1_DEVICE_CONNECTED(x) ((x) & BIT(0))
+
+/* HDCP2.0 Compliant repeater in downstream */
+#define HDCP_2_2_HDCP_2_0_REP_CONNECTED(x) ((x) & BIT(1))
+#define HDCP_2_2_MAX_CASCADE_EXCEEDED(x) ((x) & BIT(2))
+#define HDCP_2_2_MAX_DEVS_EXCEEDED(x) ((x) & BIT(3))
+#define HDCP_2_2_DEV_COUNT_LO(x) (((x) & (0xF << 4)) >> 4)
+#define HDCP_2_2_DEV_COUNT_HI(x) ((x) & BIT(0))
+#define HDCP_2_2_DEPTH(x) (((x) & (0x7 << 1)) >> 1)
+
+struct hdcp2_cert_rx {
+ u8 receiver_id[HDCP_2_2_RECEIVER_ID_LEN];
+ u8 kpub_rx[HDCP_2_2_K_PUB_RX_LEN];
+ u8 reserved[2];
+ u8 dcp_signature[HDCP_2_2_DCP_LLC_SIG_LEN];
+} __packed;
+
+struct hdcp2_streamid_type {
+ u8 stream_id;
+ u8 stream_type;
+} __packed;
+
+/*
+ * The TxCaps field specified in the HDCP HDMI, DP specs
+ * This
[PATCH 4/4] drm/i915: Define Intel HDCP2.2 registers
Intel HDCP2.2 registers are defined with addr offsets and bit details.
v2:
Replaced the arith calc with _PICK [Sean Paul]
v3:
No changes.
v4:
%s/HDCP2_CTR_DDI/HDCP2_CTL_DDI [Uma]
v5:
Added parentheses for the parameters of macro.
v6:
No changes
v7:
No changes
Signed-off-by: Ramalingam C
Reviewed-by: Sean Paul
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/i915_reg.h | 32
1 file changed, 32 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 69eb573348b3..934722693477 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -9038,6 +9038,38 @@ enum skl_power_gate {
#define HDCP_STATUS_CIPHERBIT(16)
#define HDCP_STATUS_FRAME_CNT(x) (((x) >> 8) & 0xff)
+/* HDCP2.2 Registers */
+#define _PORTA_HDCP2_BASE 0x66800
+#define _PORTB_HDCP2_BASE 0x66500
+#define _PORTC_HDCP2_BASE 0x66600
+#define _PORTD_HDCP2_BASE 0x66700
+#define _PORTE_HDCP2_BASE 0x66A00
+#define _PORTF_HDCP2_BASE 0x66900
+#define _PORT_HDCP2_BASE(port, x) _MMIO(_PICK((port), \
+ _PORTA_HDCP2_BASE, \
+ _PORTB_HDCP2_BASE, \
+ _PORTC_HDCP2_BASE, \
+ _PORTD_HDCP2_BASE, \
+ _PORTE_HDCP2_BASE, \
+ _PORTF_HDCP2_BASE) + (x))
+
+#define HDCP2_AUTH_DDI(port) _PORT_HDCP2_BASE(port, 0x98)
+#define AUTH_LINK_AUTHENTICATED BIT(31)
+#define AUTH_LINK_TYPE BIT(30)
+#define AUTH_FORCE_CLR_INPUTCTR BIT(19)
+#define AUTH_CLR_KEYSBIT(18)
+
+#define HDCP2_CTL_DDI(port)_PORT_HDCP2_BASE(port, 0xB0)
+#define CTL_LINK_ENCRYPTION_REQ BIT(31)
+
+#define HDCP2_STATUS_DDI(port) _PORT_HDCP2_BASE(port, 0xB4)
+#define STREAM_ENCRYPTION_STATUS_A BIT(31)
+#define STREAM_ENCRYPTION_STATUS_B BIT(30)
+#define STREAM_ENCRYPTION_STATUS_C BIT(29)
+#define LINK_TYPE_STATUS BIT(22)
+#define LINK_AUTH_STATUS BIT(21)
+#define LINK_ENCRYPTION_STATUS BIT(20)
+
/* Per-pipe DDI Function Control */
#define _TRANS_DDI_FUNC_CTL_A 0x60400
#define _TRANS_DDI_FUNC_CTL_B 0x61400
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/4] drm: HDMI and DP specific HDCP2.2 defines
This patch adds HDCP register definitions for HDMI and DP HDCP
adaptations.
HDMI specific HDCP2.2 register definitions are added into drm_hdcp.h,
where as HDCP2.2 register offsets in DPCD offsets are defined at
drm_dp_helper.h.
v2:
bit_field definitions are replaced by macros. [Tomas and Jani]
v3:
No Changes.
v4:
Comments style and typos are fixed [Uma]
v5:
Fix for macros.
v6:
Adds _MS to the timeouts to represent units [Sean Paul]
v7:
Macro DP_HDCP_2_2_REG_EKH_KM_OFFSET renamed [Uma]
Redundant macro is removed [Uma]
Signed-off-by: Ramalingam C
Reviewed-by: Sean Paul
---
include/drm/drm_dp_helper.h | 51 +
include/drm/drm_hdcp.h | 28 +
2 files changed, 79 insertions(+)
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 9ad98e8d9ede..4c714134a83b 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -907,6 +907,57 @@
#define DP_AUX_HDCP_KSV_FIFO 0x6802C
#define DP_AUX_HDCP_AINFO 0x6803B
+/* DP HDCP2.2 parameter offsets in DPCD address space */
+#define DP_HDCP_2_2_REG_RTX_OFFSET 0x69000
+#define DP_HDCP_2_2_REG_TXCAPS_OFFSET 0x69008
+#define DP_HDCP_2_2_REG_CERT_RX_OFFSET 0x6900B
+#define DP_HDCP_2_2_REG_RRX_OFFSET 0x69215
+#define DP_HDCP_2_2_REG_RX_CAPS_OFFSET 0x6921D
+#define DP_HDCP_2_2_REG_EKPUB_KM_OFFSET0x69220
+#define DP_HDCP_2_2_REG_EKH_KM_WR_OFFSET 0x692A0
+#define DP_HDCP_2_2_REG_M_OFFSET 0x692B0
+#define DP_HDCP_2_2_REG_HPRIME_OFFSET 0x692C0
+#define DP_HDCP_2_2_REG_EKH_KM_RD_OFFSET 0x692E0
+#define DP_HDCP_2_2_REG_RN_OFFSET 0x692F0
+#define DP_HDCP_2_2_REG_LPRIME_OFFSET 0x692F8
+#define DP_HDCP_2_2_REG_EDKEY_KS_OFFSET0x69318
+#defineDP_HDCP_2_2_REG_RIV_OFFSET 0x69328
+#define DP_HDCP_2_2_REG_RXINFO_OFFSET 0x69330
+#define DP_HDCP_2_2_REG_SEQ_NUM_V_OFFSET 0x69332
+#define DP_HDCP_2_2_REG_VPRIME_OFFSET 0x69335
+#define DP_HDCP_2_2_REG_RECV_ID_LIST_OFFSET0x69345
+#define DP_HDCP_2_2_REG_V_OFFSET 0x693E0
+#define DP_HDCP_2_2_REG_SEQ_NUM_M_OFFSET 0x693F0
+#define DP_HDCP_2_2_REG_K_OFFSET 0x693F3
+#define DP_HDCP_2_2_REG_STREAM_ID_TYPE_OFFSET 0x693F5
+#define DP_HDCP_2_2_REG_MPRIME_OFFSET 0x69473
+#define DP_HDCP_2_2_REG_RXSTATUS_OFFSET0x69493
+#define DP_HDCP_2_2_REG_STREAM_TYPE_OFFSET 0x69494
+#define DP_HDCP_2_2_REG_DBG_OFFSET 0x69518
+
+/* DP HDCP message start offsets in DPCD address space */
+#define DP_HDCP_2_2_AKE_INIT_OFFSETDP_HDCP_2_2_REG_RTX_OFFSET
+#define DP_HDCP_2_2_AKE_SEND_CERT_OFFSET DP_HDCP_2_2_REG_CERT_RX_OFFSET
+#define DP_HDCP_2_2_AKE_NO_STORED_KM_OFFSETDP_HDCP_2_2_REG_EKPUB_KM_OFFSET
+#define DP_HDCP_2_2_AKE_STORED_KM_OFFSET DP_HDCP_2_2_REG_EKH_KM_WR_OFFSET
+#define DP_HDCP_2_2_AKE_SEND_HPRIME_OFFSET DP_HDCP_2_2_REG_HPRIME_OFFSET
+#define DP_HDCP_2_2_AKE_SEND_PAIRING_INFO_OFFSET \
+ DP_HDCP_2_2_REG_EKH_KM_RD_OFFSET
+#define DP_HDCP_2_2_LC_INIT_OFFSET DP_HDCP_2_2_REG_RN_OFFSET
+#define DP_HDCP_2_2_LC_SEND_LPRIME_OFFSET DP_HDCP_2_2_REG_LPRIME_OFFSET
+#define DP_HDCP_2_2_SKE_SEND_EKS_OFFSET
DP_HDCP_2_2_REG_EDKEY_KS_OFFSET
+#define DP_HDCP_2_2_REP_SEND_RECVID_LIST_OFFSET
DP_HDCP_2_2_REG_RXINFO_OFFSET
+#define DP_HDCP_2_2_REP_SEND_ACK_OFFSETDP_HDCP_2_2_REG_V_OFFSET
+#define DP_HDCP_2_2_REP_STREAM_MANAGE_OFFSET DP_HDCP_2_2_REG_SEQ_NUM_M_OFFSET
+#define DP_HDCP_2_2_REP_STREAM_READY_OFFSETDP_HDCP_2_2_REG_MPRIME_OFFSET
+
+#define HDCP_2_2_DP_RXSTATUS_LEN 1
+#define HDCP_2_2_DP_RXSTATUS_READY(x) ((x) & BIT(0))
+#define HDCP_2_2_DP_RXSTATUS_H_PRIME(x)((x) & BIT(1))
+#define HDCP_2_2_DP_RXSTATUS_PAIRING(x)((x) & BIT(2))
+#define HDCP_2_2_DP_RXSTATUS_REAUTH_REQ(x) ((x) & BIT(3))
+#define HDCP_2_2_DP_RXSTATUS_LINK_FAILED(x)((x) & BIT(4))
+
/* DP 1.2 Sideband message defines */
/* peer device type - DP 1.2a Table 2-92 */
#define DP_PEER_DEVICE_NONE0x0
diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h
index 7cd7269c7c7b..a6de09c5e47f 100644
--- a/include/drm/drm_hdcp.h
+++ b/include/drm/drm_hdcp.h
@@ -222,4 +222,32 @@ struct hdcp2_dp_errata_stream_type {
u8 stream_type;
} __packed;
+/* HDCP2.2 TIMEOUTs in mSec */
+#define HDCP_2_2_CERT_TIMEOUT_MS 100
+#define HDCP_2_2_HPRIME_NO_PAIRED_TIMEOUT_MS 1000
+#define HDCP_2_2_HPRIME_PAIRED_TIMEOUT_MS 200
+#define HDCP_2_2_PAIRING_TIMEOUT_MS200
+#defineHDCP_2_2_HDMI_LPRIME_TIMEOUT_MS 20
+#define HDCP_2_2_DP_LPRIME_TIMEOUT_MS 7
+#define HDCP_2_2_RECVID_LIST_TIMEOUT_MS3000
+#define HDCP_2_2_STREAM_READY_TIMEOUT_MS
[PATCH 0/4] Implement HDCP2.2: PART-I
This series defines the HDCP2.2 authentication messages at drm header along with intel specific HDCP2.2 registers. And introduces a structure intel_hdcp to wrap all hdcp related variables into it. These patches were previously reviewed at https://patchwork.freedesktop.org/series/38254/ Ramalingam C (4): drm: hdcp2.2 authentication msg definitions drm: HDMI and DP specific HDCP2.2 defines drm/i915: wrapping all hdcp var into intel_hdcp drm/i915: Define Intel HDCP2.2 registers drivers/gpu/drm/i915/i915_debugfs.c | 2 +- drivers/gpu/drm/i915/i915_reg.h | 32 ++ drivers/gpu/drm/i915/intel_display.c | 6 +- drivers/gpu/drm/i915/intel_drv.h | 15 ++- drivers/gpu/drm/i915/intel_hdcp.c| 109 ++ include/drm/drm_dp_helper.h | 51 + include/drm/drm_hdcp.h | 212 +++ 7 files changed, 369 insertions(+), 58 deletions(-) -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 18/28] drm/i915/dp: Enable/Disable DSC in DP Sink
On Wed, Oct 24, 2018 at 03:28:30PM -0700, Manasi Navare wrote:
> From: Gaurav K Singh
>
> This patch enables decompression support in sink device
> before link training and disables the same during the
> DDI disabling.
>
> v2:(From Manasi)
> * Change the enable/disable function to take crtc_state
> instead of intel_dp as an argument (Manasi)
> * Use the compression_enable flag as part of crtc_state (Manasi)
>
> Cc: Jani Nikula
> Cc: Ville Syrjala
> Cc: Anusha Srivatsa
> Cc: Gaurav K Singh
> Signed-off-by: Gaurav K Singh
> Signed-off-by: Manasi Navare
> Reviewed-by: Anusha Srivatsa
> ---
> drivers/gpu/drm/i915/intel_ddi.c | 5 +
> drivers/gpu/drm/i915/intel_dp.c | 15 +++
> drivers/gpu/drm/i915/intel_drv.h | 3 +++
> 3 files changed, 23 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index e40a8c97d34b..1de0a3917d7f 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -2930,6 +2930,8 @@ static void intel_ddi_pre_enable_dp(struct
> intel_encoder *encoder,
> intel_ddi_init_dp_buf_reg(encoder);
> if (!is_mst)
> intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
> + intel_dp_sink_set_decompression_state(intel_dp, crtc_state,
> + DP_DECOMPRESSION_EN);
> intel_dp_start_link_train(intel_dp);
> if (port != PORT_A || INTEL_GEN(dev_priv) >= 9)
> intel_dp_stop_link_train(intel_dp);
> @@ -3272,6 +3274,9 @@ static void intel_disable_ddi_dp(struct intel_encoder
> *encoder,
> intel_edp_drrs_disable(intel_dp, old_crtc_state);
> intel_psr_disable(intel_dp, old_crtc_state);
> intel_edp_backlight_off(old_conn_state);
> + /* Disable the decompression in DP Sink */
> + intel_dp_sink_set_decompression_state(intel_dp, old_crtc_state,
> + ~DP_DECOMPRESSION_EN);
That looks suspicious.
I can't figure out what value you're actually passing here since I
can't find the definiiton of DP_DECOMPRESSION_EN anywhere.
> }
>
> static void intel_disable_ddi_hdmi(struct intel_encoder *encoder,
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 35162c3bc811..72e6605f0ed7 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -3005,6 +3005,21 @@ static bool downstream_hpd_needs_d0(struct intel_dp
> *intel_dp)
> intel_dp->downstream_ports[0] & DP_DS_PORT_HPD;
> }
>
> +void intel_dp_sink_set_decompression_state(struct intel_dp *intel_dp,
> +const struct intel_crtc_state
> *crtc_state,
> +int state)
> +{
> + int ret;
> +
> + if (!crtc_state->dsc_params.compression_enable)
> + return;
> +
> + ret = drm_dp_dpcd_writeb(_dp->aux, DP_DSC_ENABLE, state);
> + if (ret < 0)
> + DRM_DEBUG_KMS("Failed to %s sink decompression state\n",
> + state == DP_DECOMPRESSION_EN ? "enable" :
> "disable");
> +}
> +
> /* If the sink supports it, try to set the power state appropriately */
> void intel_dp_sink_dpms(struct intel_dp *intel_dp, int mode)
> {
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index c4be4ba7adac..4f5d17bcd54e 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1786,6 +1786,9 @@ void intel_dp_stop_link_train(struct intel_dp
> *intel_dp);
> int intel_dp_retrain_link(struct intel_encoder *encoder,
> struct drm_modeset_acquire_ctx *ctx);
> void intel_dp_sink_dpms(struct intel_dp *intel_dp, int mode);
> +void intel_dp_sink_set_decompression_state(struct intel_dp *intel_dp,
> +const struct intel_crtc_state
> *crtc_state,
> +int state);
> void intel_dp_encoder_reset(struct drm_encoder *encoder);
> void intel_dp_encoder_suspend(struct intel_encoder *intel_encoder);
> void intel_dp_encoder_destroy(struct drm_encoder *encoder);
> --
> 2.18.0
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108521] RX 580 as eGPU amdgpu: gpu post error!
https://bugs.freedesktop.org/show_bug.cgi?id=108521 --- Comment #18 from Robert Strube --- Created attachment 142204 --> https://bugs.freedesktop.org/attachment.cgi?id=142204=edit sudo cat /proc/iomem *with* eGPU connected at boot -- 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 108521] RX 580 as eGPU amdgpu: gpu post error!
https://bugs.freedesktop.org/show_bug.cgi?id=108521 Robert Strube changed: What|Removed |Added Attachment #142205|fresh dmesg log booting |fresh dmesg log booting description|system *wite* eGPU |system *with* eGPU |connected at boot |connected at boot -- 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 108521] RX 580 as eGPU amdgpu: gpu post error!
https://bugs.freedesktop.org/show_bug.cgi?id=108521 --- Comment #19 from Robert Strube --- Created attachment 142205 --> https://bugs.freedesktop.org/attachment.cgi?id=142205=edit fresh dmesg log booting system *wite* eGPU connected at boot -- 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: fix call_kern.cocci warnings v3
在 2018/10/25 18:36, Maarten Lankhorst 写道:
> Op 25-10-18 om 12:21 schreef Chunming Zhou:
>> drivers/gpu/drm/drm_syncobj.c:202:4-14: ERROR: function
>> drm_syncobj_find_signal_pt_for_point called on line 390 inside lock on line
>> 389 but uses GFP_KERNEL
>>
>>Find functions that refer to GFP_KERNEL but are called with locks held.
>>
>> Generated by: scripts/coccinelle/locks/call_kern.cocci
>>
>> v2:
>> syncobj->timeline still needs protect.
>>
>> v3:
>> use a global signaled fence instead of re-allocation.
>>
>> Signed-off-by: Chunming Zhou
>> Cc: Maarten Lankhorst
>> Cc: intel-...@lists.freedesktop.org
>> Cc: Christian König
>> ---
>> drivers/gpu/drm/drm_drv.c | 2 ++
>> drivers/gpu/drm/drm_syncobj.c | 52 +--
>> include/drm/drm_syncobj.h | 1 +
>> 3 files changed, 34 insertions(+), 21 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
>> index 36e8e9cbec52..0a6f1023d6c3 100644
>> --- a/drivers/gpu/drm/drm_drv.c
>> +++ b/drivers/gpu/drm/drm_drv.c
>> @@ -37,6 +37,7 @@
>> #include
>> #include
>> #include
>> +#include
>>
>> #include "drm_crtc_internal.h"
>> #include "drm_legacy.h"
>> @@ -1003,6 +1004,7 @@ static int __init drm_core_init(void)
>> if (ret < 0)
>> goto error;
>>
>> +drm_syncobj_stub_fence_init();
>> drm_core_init_complete = true;
>>
>> DRM_DEBUG("Initialized\n");
>> diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
>> index b7eaa603f368..6b3f5a06e4d3 100644
>> --- a/drivers/gpu/drm/drm_syncobj.c
>> +++ b/drivers/gpu/drm/drm_syncobj.c
>> @@ -80,6 +80,27 @@ struct drm_syncobj_signal_pt {
>> struct list_head list;
>> };
>>
>> +static struct drm_syncobj_stub_fence stub_signaled_fence;
>> +static void global_stub_fence_release(struct dma_fence *fence)
>> +{
>> +/* it is impossible to come here */
>> +BUG();
>> +}
> WARN_ON_ONCE(1)? No need to halt the machine.
>
>> +static const struct dma_fence_ops global_stub_fence_ops = {
>> +.get_driver_name = drm_syncobj_stub_fence_get_name,
>> +.get_timeline_name = drm_syncobj_stub_fence_get_name,
>> +.release = global_stub_fence_release,
>> +};
>> +
>> +void drm_syncobj_stub_fence_init(void)
>> +{
>> +spin_lock_init(_signaled_fence.lock);
>> +dma_fence_init(_signaled_fence.base,
>> + _stub_fence_ops,
>> + _signaled_fence.lock,
>> + 0, 0);
>> +dma_fence_signal(_signaled_fence.base);
>> +}
>> /**
>>* drm_syncobj_find - lookup and reference a sync object.
>>* @file_private: drm file private pointer
>> @@ -111,24 +132,14 @@ static struct dma_fence
>>uint64_t point)
>> {
>> struct drm_syncobj_signal_pt *signal_pt;
>> +struct dma_fence *f = NULL;
>>
>> +spin_lock(>pt_lock);
>> if ((syncobj->type == DRM_SYNCOBJ_TYPE_TIMELINE) &&
>> (point <= syncobj->timeline)) {
>> -struct drm_syncobj_stub_fence *fence =
>> -kzalloc(sizeof(struct drm_syncobj_stub_fence),
>> -GFP_KERNEL);
>> -
>> -if (!fence)
>> -return NULL;
>> -spin_lock_init(>lock);
>> -dma_fence_init(>base,
>> - _syncobj_stub_fence_ops,
>> - >lock,
>> - syncobj->timeline_context,
>> - point);
>> -
>> -dma_fence_signal(>base);
>> -return >base;
>> +dma_fence_get(_signaled_fence.base);
>> +spin_unlock(>pt_lock);
>> +return _signaled_fence.base;
>> }
>>
>> list_for_each_entry(signal_pt, >signal_pt_list, list) {
>> @@ -137,9 +148,12 @@ static struct dma_fence
>> if ((syncobj->type == DRM_SYNCOBJ_TYPE_BINARY) &&
>> (point != signal_pt->value))
>> continue;
>> -return dma_fence_get(_pt->fence_array->base);
>> +f = dma_fence_get(_pt->fence_array->base);
>> +break;
>> }
>> -return NULL;
>> +spin_unlock(>pt_lock);
>> +
>> +return f;
>> }
>>
>> static void drm_syncobj_add_callback_locked(struct drm_syncobj *syncobj,
>> @@ -166,9 +180,7 @@ static void drm_syncobj_fence_get_or_add_callback(struct
>> drm_syncobj *syncobj,
>> }
>>
>> mutex_lock(>cb_mutex);
>> -spin_lock(>pt_lock);
>> *fence = drm_syncobj_find_signal_pt_for_point(syncobj, pt_value);
>> -spin_unlock(>pt_lock);
>> if (!*fence)
>> drm_syncobj_add_callback_locked(syncobj, cb, func);
>> mutex_unlock(>cb_mutex);
>> @@ -379,11 +391,9 @@ drm_syncobj_point_get(struct drm_syncobj *syncobj, u64
>> point, u64 flags,
>> if (ret < 0)
>> return ret;
>> }
>> -spin_lock(>pt_lock);
>> *fence = drm_syncobj_find_signal_pt_for_point(syncobj,
[PATCH v2 2/3] drm/vc4: Report underrun errors
The DRM framework provides a generic way to report underrun errors.
Let's implement the necessary hooks to support it in the VC4 driver.
Signed-off-by: Boris Brezillon
---
Changes in v2:
- New patch
---
drivers/gpu/drm/vc4/vc4_drv.h | 3 ++
drivers/gpu/drm/vc4/vc4_hvs.c | 71 ++
drivers/gpu/drm/vc4/vc4_kms.c | 7
drivers/gpu/drm/vc4/vc4_regs.h | 46 ++
4 files changed, 92 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
index bd6ef1f31822..a6c67c65ffbc 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.h
+++ b/drivers/gpu/drm/vc4/vc4_drv.h
@@ -763,6 +763,9 @@ void vc4_irq_reset(struct drm_device *dev);
extern struct platform_driver vc4_hvs_driver;
void vc4_hvs_dump_state(struct drm_device *dev);
int vc4_hvs_debugfs_regs(struct seq_file *m, void *unused);
+void vc4_hvs_unmask_underrun(struct drm_device *dev);
+void vc4_hvs_mask_underrun(struct drm_device *dev);
+void vc4_hvs_clear_underrun(struct drm_device *dev);
/* vc4_kms.c */
int vc4_kms_load(struct drm_device *dev);
diff --git a/drivers/gpu/drm/vc4/vc4_hvs.c b/drivers/gpu/drm/vc4/vc4_hvs.c
index 5d8c749c9749..12ff95ff1d29 100644
--- a/drivers/gpu/drm/vc4/vc4_hvs.c
+++ b/drivers/gpu/drm/vc4/vc4_hvs.c
@@ -22,6 +22,7 @@
* each CRTC.
*/
+#include
#include
#include "vc4_drv.h"
#include "vc4_regs.h"
@@ -166,6 +167,58 @@ static int vc4_hvs_upload_linear_kernel(struct vc4_hvs
*hvs,
return 0;
}
+static irqreturn_t vc4_hvs_irq_handler(int irq, void *data)
+{
+ struct drm_device *dev = data;
+ struct vc4_dev *vc4 = to_vc4_dev(dev);
+ u32 status;
+
+ status = HVS_READ(SCALER_DISPSTAT);
+
+ if (status &
+ (SCALER_DISPSTAT_EUFLOW(0) | SCALER_DISPSTAT_EUFLOW(1) |
+SCALER_DISPSTAT_EUFLOW(2)))
+ drm_atomic_helper_underrun_set(dev);
+
+ HVS_WRITE(SCALER_DISPSTAT, status);
+
+ return status ? IRQ_HANDLED : IRQ_NONE;
+}
+
+void vc4_hvs_mask_underrun(struct drm_device *dev)
+{
+ struct vc4_dev *vc4 = to_vc4_dev(dev);
+ u32 dispctrl = HVS_READ(SCALER_DISPCTRL);
+
+ dispctrl &= ~(SCALER_DISPCTRL_DSPEISLUR(0) |
+ SCALER_DISPCTRL_DSPEISLUR(1) |
+ SCALER_DISPCTRL_DSPEISLUR(2));
+
+ HVS_WRITE(SCALER_DISPCTRL, dispctrl);
+}
+
+void vc4_hvs_clear_underrun(struct drm_device *dev)
+{
+ struct vc4_dev *vc4 = to_vc4_dev(dev);
+
+ HVS_WRITE(SCALER_DISPSTAT,
+ SCALER_DISPSTAT_EUFLOW(0) |
+ SCALER_DISPSTAT_EUFLOW(1) |
+ SCALER_DISPSTAT_EUFLOW(2));
+}
+
+void vc4_hvs_unmask_underrun(struct drm_device *dev)
+{
+ struct vc4_dev *vc4 = to_vc4_dev(dev);
+ u32 dispctrl = HVS_READ(SCALER_DISPCTRL);
+
+ dispctrl |= SCALER_DISPCTRL_DSPEISLUR(0) |
+ SCALER_DISPCTRL_DSPEISLUR(1) |
+ SCALER_DISPCTRL_DSPEISLUR(2);
+
+ HVS_WRITE(SCALER_DISPCTRL, dispctrl);
+}
+
static int vc4_hvs_bind(struct device *dev, struct device *master, void *data)
{
struct platform_device *pdev = to_platform_device(dev);
@@ -219,15 +272,33 @@ static int vc4_hvs_bind(struct device *dev, struct device
*master, void *data)
dispctrl = HVS_READ(SCALER_DISPCTRL);
dispctrl |= SCALER_DISPCTRL_ENABLE;
+ dispctrl |= SCALER_DISPCTRL_DSPEISLUR(0) | SCALER_DISPCTRL_DISPEIRQ(0) |
+ SCALER_DISPCTRL_DSPEISLUR(1) | SCALER_DISPCTRL_DISPEIRQ(1) |
+ SCALER_DISPCTRL_DSPEISLUR(2) | SCALER_DISPCTRL_DISPEIRQ(2);
/* Set DSP3 (PV1) to use HVS channel 2, which would otherwise
* be unused.
*/
dispctrl &= ~SCALER_DISPCTRL_DSP3_MUX_MASK;
+ dispctrl &= ~(SCALER_DISPCTRL_DMAEIRQ |
+ SCALER_DISPCTRL_SLVWREIRQ |
+ SCALER_DISPCTRL_SLVRDEIRQ |
+ SCALER_DISPCTRL_DSPEIEOF(0) |
+ SCALER_DISPCTRL_DSPEIEOF(1) |
+ SCALER_DISPCTRL_DSPEIEOF(2) |
+ SCALER_DISPCTRL_DSPEIEOLN(0) |
+ SCALER_DISPCTRL_DSPEIEOLN(1) |
+ SCALER_DISPCTRL_DSPEIEOLN(2) |
+ SCALER_DISPCTRL_SCLEIRQ);
dispctrl |= VC4_SET_FIELD(2, SCALER_DISPCTRL_DSP3_MUX);
HVS_WRITE(SCALER_DISPCTRL, dispctrl);
+ ret = devm_request_irq(dev, platform_get_irq(pdev, 0),
+ vc4_hvs_irq_handler, 0, "vc4 hvs", drm);
+ if (ret)
+ return ret;
+
return 0;
}
diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
index 5c9823ccb3f8..8e0183b1e8bb 100644
--- a/drivers/gpu/drm/vc4/vc4_kms.c
+++ b/drivers/gpu/drm/vc4/vc4_kms.c
@@ -139,6 +139,8 @@ vc4_atomic_complete_commit(struct drm_atomic_state *state)
struct drm_device *dev = state->dev;
struct vc4_dev *vc4 = to_vc4_dev(dev);
+ drm_atomic_helper_underrun_stop(dev);
+
[PATCH v2 1/3] drm/atomic: Add a generic infrastructure to track underrun errors
Display controllers usually provide a lot features like overlay planes,
hardware scalers, hardware rotations, ...
Most of the time those features work just fine when enabled
independently, but activating all of them at the same time tend to
show other limitations like the limited memory bus or scaler
bandwidth.
This sort of bandwidth estimation is hard to get right, and we
sometimes fail to predict that a specific workload will not pass,
which will most likely result in underrun errors somewhere in the
display pipeline (most of the time at the CRTC level).
This path aims at making underrun error tracking generic and exposing
underrun errors to userspace through a debugfs file.
This way, CI tools like IGT, can try to enable a bunch of features and
if such underrun errors are reported after the settings have been
accepted and applied by the KMS infrastructure. When that happens it
means the load tracking algorithm needs some tweaking/fixing.
Signed-off-by: Boris Brezillon
---
Changes in v2:
- New patch
---
drivers/gpu/drm/drm_atomic.c| 12 +++
drivers/gpu/drm/drm_atomic_helper.c | 4 +++
include/drm/drm_atomic_helper.h | 53 +
include/drm/drm_device.h| 15
include/drm/drm_mode_config.h | 26 ++
5 files changed, 110 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 0e27d45feba9..350348961ab3 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1179,9 +1179,21 @@ static int drm_state_info(struct seq_file *m, void *data)
return 0;
}
+static int drm_underrun_info(struct seq_file *m, void *data)
+{
+ struct drm_info_node *node = m->private;
+ struct drm_device *dev = node->minor->dev;
+ struct drm_printer p = drm_seq_file_printer(m);
+
+ drm_printf(, "%c\n", atomic_read(>underrun) ? 'Y' : 'N');
+
+ return 0;
+}
+
/* any use in debugfs files to dump individual planes/crtc/etc? */
static const struct drm_info_list drm_atomic_debugfs_list[] = {
{"state", drm_state_info, 0},
+ {"underrun", drm_underrun_info, 0 },
};
int drm_atomic_debugfs_init(struct drm_minor *minor)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 6f66777dca4b..9956c2928c5b 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1456,6 +1456,8 @@ void drm_atomic_helper_commit_tail(struct
drm_atomic_state *old_state)
{
struct drm_device *dev = old_state->dev;
+ drm_atomic_helper_underrun_stop(dev);
+
drm_atomic_helper_commit_modeset_disables(dev, old_state);
drm_atomic_helper_commit_planes(dev, old_state, 0);
@@ -1466,6 +1468,8 @@ void drm_atomic_helper_commit_tail(struct
drm_atomic_state *old_state)
drm_atomic_helper_commit_hw_done(old_state);
+ drm_atomic_helper_underrun_start(dev);
+
drm_atomic_helper_wait_for_vblanks(dev, old_state);
drm_atomic_helper_cleanup_planes(dev, old_state);
diff --git a/include/drm/drm_atomic_helper.h b/include/drm/drm_atomic_helper.h
index 25ca0097563e..f712144dd26d 100644
--- a/include/drm/drm_atomic_helper.h
+++ b/include/drm/drm_atomic_helper.h
@@ -221,4 +221,57 @@ drm_atomic_plane_disabling(struct drm_plane_state
*old_plane_state,
return old_plane_state->crtc && !new_plane_state->crtc;
}
+/**
+ * drm_atomic_helper_underrun_set() - Set the underrun bit
+ * @dev: device the underrun happened on
+ *
+ * This function should be called when an underrun happens after an update
+ * has been committed to the device.
+ * Underrun interrupts are masked to avoid flooding the CPU with useless
+ * interrupts.
+ */
+static inline void drm_atomic_helper_underrun_set(struct drm_device *dev)
+{
+ atomic_set(>underrun, 1);
+
+ if (dev->mode_config.funcs->atomic_mask_underrun)
+ dev->mode_config.funcs->atomic_mask_underrun(dev);
+}
+
+/**
+ * drm_atomic_helper_underrun_stop() - Stop generating underrun events
+ * @dev: device we want to stop underrun on
+ *
+ * This function should be called in the atomic commit path, just before
+ * committing changes to the hardware.
+ * The underrun interrupt is simply masked prior to getting underrun events
+ * while we are applying the new config.
+ */
+static inline void drm_atomic_helper_underrun_stop(struct drm_device *dev)
+{
+ if (dev->mode_config.funcs->atomic_mask_underrun)
+ dev->mode_config.funcs->atomic_mask_underrun(dev);
+}
+
+/**
+ * drm_atomic_helper_underrun_start() - Start listening to underrun events
+ * @dev: device we want to start underrun on
+ *
+ * This function should be called in the atomic commit path, just after
+ * the changes have been committed to the hardware.
+ * Any pending underrun events are cleared before unmasking the interrupt to
+ * guarantee that further underrun events are really caused by the new
+ * configuration.
+ */
[PATCH v2 3/3] drm/vc4: Add a load tracker to prevent HVS underflow errors
The HVS block is supposed to fill the pixelvalve FIFOs fast enough to
meet the requested framerate. The problem is, the HVS and memory bus
bandwidths are limited, and if we don't take these limitations into
account we might end up with HVS underflow errors.
This patch is trying to model the per-plane HVS and memory bus bandwidth
consumption and take a decision at atomic_check() time whether the
estimated load will fit in the HVS and membus budget.
Note that we take an extra margin on the memory bus consumption to let
the system run smoothly when other blocks are doing heavy use of the
memory bus. Same goes for the HVS limit, except the margin is smaller in
this case, since the HVS is not used by external components.
Signed-off-by: Boris Brezillon
---
Changes in v2:
- Remove an unused var in vc4_load_tracker_atomic_check()
---
drivers/gpu/drm/vc4/vc4_drv.c | 1 +
drivers/gpu/drm/vc4/vc4_drv.h | 11
drivers/gpu/drm/vc4/vc4_kms.c | 103 +++-
drivers/gpu/drm/vc4/vc4_plane.c | 60 +++
4 files changed, 174 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c
index f6f5cd80c04d..7195a0bcceb3 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.c
+++ b/drivers/gpu/drm/vc4/vc4_drv.c
@@ -313,6 +313,7 @@ static void vc4_drm_unbind(struct device *dev)
drm_mode_config_cleanup(drm);
+ drm_atomic_private_obj_fini(>load_tracker);
drm_atomic_private_obj_fini(>ctm_manager);
drm_dev_put(drm);
diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
index a6c67c65ffbc..11369da944b6 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.h
+++ b/drivers/gpu/drm/vc4/vc4_drv.h
@@ -200,6 +200,7 @@ struct vc4_dev {
struct drm_modeset_lock ctm_state_lock;
struct drm_private_obj ctm_manager;
+ struct drm_private_obj load_tracker;
};
static inline struct vc4_dev *
@@ -369,6 +370,16 @@ struct vc4_plane_state {
* to enable background color fill.
*/
bool needs_bg_fill;
+
+ /* Load of this plane on the HVS block. The load is expressed in HVS
+* cycles/sec.
+*/
+ u64 hvs_load;
+
+ /* Memory bandwidth needed for this plane. This is expressed in
+* bytes/sec.
+*/
+ u64 membus_load;
};
static inline struct vc4_plane_state *
diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
index 8e0183b1e8bb..b905a19c1470 100644
--- a/drivers/gpu/drm/vc4/vc4_kms.c
+++ b/drivers/gpu/drm/vc4/vc4_kms.c
@@ -34,6 +34,18 @@ static struct vc4_ctm_state *to_vc4_ctm_state(struct
drm_private_state *priv)
return container_of(priv, struct vc4_ctm_state, base);
}
+struct vc4_load_tracker_state {
+ struct drm_private_state base;
+ u64 hvs_load;
+ u64 membus_load;
+};
+
+static struct vc4_load_tracker_state *
+to_vc4_load_tracker_state(struct drm_private_state *priv)
+{
+ return container_of(priv, struct vc4_load_tracker_state, base);
+}
+
static struct vc4_ctm_state *vc4_get_ctm_state(struct drm_atomic_state *state,
struct drm_private_obj *manager)
{
@@ -383,6 +395,81 @@ vc4_ctm_atomic_check(struct drm_device *dev, struct
drm_atomic_state *state)
return 0;
}
+static int vc4_load_tracker_atomic_check(struct drm_atomic_state *state)
+{
+ struct drm_plane_state *old_plane_state, *new_plane_state;
+ struct vc4_dev *vc4 = to_vc4_dev(state->dev);
+ struct vc4_load_tracker_state *load_state;
+ struct drm_private_state *priv_state;
+ struct drm_plane *plane;
+ int i;
+
+ priv_state = drm_atomic_get_private_obj_state(state,
+ >load_tracker);
+ if (IS_ERR(priv_state))
+ return PTR_ERR(priv_state);
+
+ load_state = to_vc4_load_tracker_state(priv_state);
+ for_each_oldnew_plane_in_state(state, plane, old_plane_state,
+ new_plane_state, i) {
+ struct vc4_plane_state *vc4_plane_state;
+
+ if (old_plane_state->fb && old_plane_state->crtc) {
+ vc4_plane_state = to_vc4_plane_state(old_plane_state);
+ load_state->membus_load -= vc4_plane_state->membus_load;
+ load_state->hvs_load -= vc4_plane_state->hvs_load;
+ }
+
+ if (new_plane_state->fb && new_plane_state->crtc) {
+ vc4_plane_state = to_vc4_plane_state(new_plane_state);
+ load_state->membus_load += vc4_plane_state->membus_load;
+ load_state->hvs_load += vc4_plane_state->hvs_load;
+ }
+ }
+
+ /* The abolsute limit is 2Gbyte/sec, but let's take a margin to let
+* the system work when other blocks are accessing the memory.
+*/
+ if (load_state->membus_load > SZ_1G + SZ_512M)
[PATCH v2 0/3] drm/vc4: Add a load tracker
Hello, This is the 2nd version of the VC4 load tracker patch. Daniel, as you suggested, I've implemented a generic infrastructure to track and report underrun errors (patch 1). Not sure this is what you had in mind, but it seems to do the job for my use case, and should allow me to easily track regressions in the load tracking logic with a bunch of IGT tests. Let me know if you want it done differently. Patch 2 is implementing the generic underrun interface in the VC4 driver, and patch 3 is just adding the load tracking logic (hasn't changed since the RFC except for the unused 'ret' var removal). Regards, Boris Boris Brezillon (3): drm/atomic: Add a generic infrastructure to track underrun errors drm/vc4: Report underrun errors drm/vc4: Add a load tracker to prevent HVS underflow errors drivers/gpu/drm/drm_atomic.c| 12 +++ drivers/gpu/drm/drm_atomic_helper.c | 4 + drivers/gpu/drm/vc4/vc4_drv.c | 1 + drivers/gpu/drm/vc4/vc4_drv.h | 14 drivers/gpu/drm/vc4/vc4_hvs.c | 71 ++ drivers/gpu/drm/vc4/vc4_kms.c | 110 +++- drivers/gpu/drm/vc4/vc4_plane.c | 60 +++ drivers/gpu/drm/vc4/vc4_regs.h | 46 +++- include/drm/drm_atomic_helper.h | 53 ++ include/drm/drm_device.h| 15 include/drm/drm_mode_config.h | 26 +++ 11 files changed, 376 insertions(+), 36 deletions(-) -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] drm-intel-next-fixes
Hi Dave, One fix to avoid applying link retraining workaround on eDP monitors that was missing Fixes: (kindly pointed out by Jani) in addition to the patches in previous PR. I also got GVT PR for -next-fixes, but it had an issue with S-o-bs, so I'll include it then in -fixes pull. Regards, Joonas *** drm-intel-next-fixes-2018-10-25: - Fix to avoid link retraining workaround on eDP (the other is a comment change) The following changes since commit f2bfc71aee75feff33ca659322b72ffeed5a243d: Merge tag 'drm-intel-next-fixes-2018-10-18' of git://anongit.freedesktop.org/drm/drm-intel into drm-next (2018-10-19 14:28:11 +1000) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-fixes-2018-10-25 for you to fetch changes up to f9776280c29e77a18cbc7ebb6d48f7885e494990: drm/i915/dp: Restrict link retrain workaround to external monitors (2018-10-24 13:48:12 +0300) - Fix to avoid link retraining workaround on eDP (the other is a comment change) Dhinakaran Pandiyan (2): drm/i915/dp: Fix link retraining comment in intel_dp_long_pulse() drm/i915/dp: Restrict link retrain workaround to external monitors Lyude Paul (4): drm/atomic_helper: Disallow new modesets on unregistered connectors drm/atomic_helper: Allow DPMS On<->Off changes for unregistered connectors drm/atomic_helper: Stop modesets on unregistered connectors harder drm/nouveau: Fix nv50_mstc->best_encoder() drivers/gpu/drm/drm_atomic_helper.c | 21 +- drivers/gpu/drm/drm_connector.c | 11 ++--- drivers/gpu/drm/i915/intel_dp.c | 20 -- drivers/gpu/drm/i915/intel_dp_mst.c | 8 ++-- drivers/gpu/drm/nouveau/dispnv50/disp.c | 14 ++- include/drm/drm_connector.h | 71 - 6 files changed, 110 insertions(+), 35 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/6] kthread: finer-grained lockdep/cross-release completion
Since -rc1 we're hitting a bunch of lockdep splats using the new
cross-release stuff around the 2 kthread completions. In all cases
they are because totally independent uses of kthread are mixed up by
lockdep into the same locking class, creating artificial deadlocks.
Fix this by converting kthread code in the same way as e.g.
alloc_workqueue already works: Use macros for the public api so we can
have a callsite specific lockdep key, then pass that through the
entire callchain. Due to the many entry points this is slightly
tedious.
Cc: Tvrtko Ursulin
Cc: Marta Lofstedt
Cc: Byungchul Park
Cc: Ingo Molnar
Cc: Peter Zijlstra
Cc: Tejun Heo
Cc: Kees Cook
Cc: Thomas Gleixner
Cc: Shaohua Li
Cc: Andrew Morton
Cc: Jens Axboe
Cc: Daniel Vetter
Cc: Greg Kroah-Hartman
Cc: Jonathan Corbet
Cc: Oleg Nesterov
References: https://bugs.freedesktop.org/show_bug.cgi?id=103950
Signed-off-by: Daniel Vetter
---
include/linux/kthread.h | 48 -
kernel/kthread.c| 68 -
2 files changed, 88 insertions(+), 28 deletions(-)
diff --git a/include/linux/kthread.h b/include/linux/kthread.h
index c1961761311d..7a9463f0be5c 100644
--- a/include/linux/kthread.h
+++ b/include/linux/kthread.h
@@ -6,10 +6,12 @@
#include
#include
-__printf(4, 5)
-struct task_struct *kthread_create_on_node(int (*threadfn)(void *data),
+__printf(6, 7)
+struct task_struct *_kthread_create_on_node(int (*threadfn)(void *data),
void *data,
int node,
+ struct lock_class_key *exited_key,
+ struct lock_class_key *parked_key,
const char namefmt[], ...);
/**
@@ -25,12 +27,27 @@ struct task_struct *kthread_create_on_node(int
(*threadfn)(void *data),
*/
#define kthread_create(threadfn, data, namefmt, arg...) \
kthread_create_on_node(threadfn, data, NUMA_NO_NODE, namefmt, ##arg)
+#define kthread_create_on_node(threadfn, data, node, namefmt, arg...) \
+({ \
+ static struct lock_class_key __exited_key, __parked_key;\
+ _kthread_create_on_node(threadfn, data, node, &__exited_key,\
+ &__parked_key, namefmt, ##arg); \
+})
-struct task_struct *kthread_create_on_cpu(int (*threadfn)(void *data),
+struct task_struct *_kthread_create_on_cpu(int (*threadfn)(void *data),
void *data,
unsigned int cpu,
+ struct lock_class_key *exited_key,
+ struct lock_class_key *parked_key,
const char *namefmt);
+#define kthread_create_on_cpu(threadfn, data, cpu, namefmt)\
+({ \
+ static struct lock_class_key __exited_key, __parked_key;\
+ _kthread_create_on_cpu(threadfn, data, cpu, &__exited_key,\
+ &__parked_key, namefmt); \
+})
+
/**
* kthread_run - create and wake a thread.
@@ -171,13 +188,30 @@ extern void __kthread_init_worker(struct kthread_worker
*worker,
int kthread_worker_fn(void *worker_ptr);
-__printf(2, 3)
+__printf(4, 5)
struct kthread_worker *
-kthread_create_worker(unsigned int flags, const char namefmt[], ...);
+_kthread_create_worker(unsigned int flags,
+ struct lock_class_key *exited_key,
+ struct lock_class_key *parked_key,
+ const char namefmt[], ...);
+#define kthread_create_worker(flags, namefmt...)
\
+({ \
+ static struct lock_class_key __exited_key, __parked_key;\
+ _kthread_create_worker(flags, &__exited_key, &__parked_key, \
+ ##namefmt); \
+})
-__printf(3, 4) struct kthread_worker *
-kthread_create_worker_on_cpu(int cpu, unsigned int flags,
+__printf(5, 6) struct kthread_worker *
+_kthread_create_worker_on_cpu(int cpu, unsigned int flags,
+ struct lock_class_key *exited_key,
+ struct lock_class_key *parked_key,
const char namefmt[], ...);
+#define kthread_create_worker_on_cpu(cpu, flags, namefmt...) \
+({ \
+ static struct lock_class_key __exited_key, __parked_key;\
+ _kthread_create_worker_on_cpu(cpu, flags, &__exited_key, &__parked_key,\
+ ##namefmt); \
+})
bool kthread_queue_work(struct kthread_worker
[PATCH 1/6] locking/lockdep: restore cross-release checks
This reverts the following commits: commit 527187d28569e39c5d489d6306d3b79605cf85a6 Author: Ingo Molnar Date: Mon Jan 8 17:27:19 2018 +0100 locking/lockdep: Remove cross-release leftovers commit dba04eb76df982703fefc021a4d278347b6176a9 Author: David Sterba Date: Mon Jan 8 16:27:31 2018 +0100 locking/Documentation: Remove stale crossrelease_fullstack parameter commit e966eaeeb623f09975ef362c2866fae6f86844f9 Author: Ingo Molnar Date: Tue Dec 12 12:31:16 2017 +0100 locking/lockdep: Remove the cross-release locking checks Signed-off-by: Daniel Vetter --- .../admin-guide/kernel-parameters.txt | 3 + Documentation/locking/crossrelease.txt| 874 ++ include/linux/completion.h| 46 + include/linux/irqflags.h | 4 + include/linux/lockdep.h | 127 +++ include/linux/sched.h | 11 + kernel/locking/lockdep.c | 652 - kernel/sched/completion.c | 5 + lib/Kconfig.debug | 33 + 9 files changed, 1720 insertions(+), 35 deletions(-) create mode 100644 Documentation/locking/crossrelease.txt diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index 92eb1f42240d..6ab3ad188c01 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -724,6 +724,9 @@ It will be ignored when crashkernel=X,high is not used or memory reserved is below 4G. + crossrelease_fullstack + [KNL] Allow to record full stack trace in cross-release + cryptomgr.notests [KNL] Disable crypto self-tests diff --git a/Documentation/locking/crossrelease.txt b/Documentation/locking/crossrelease.txt new file mode 100644 index ..bdf1423d5f99 --- /dev/null +++ b/Documentation/locking/crossrelease.txt @@ -0,0 +1,874 @@ +Crossrelease + + +Started by Byungchul Park + +Contents: + + (*) Background + + - What causes deadlock + - How lockdep works + + (*) Limitation + + - Limit lockdep + - Pros from the limitation + - Cons from the limitation + - Relax the limitation + + (*) Crossrelease + + - Introduce crossrelease + - Introduce commit + + (*) Implementation + + - Data structures + - How crossrelease works + + (*) Optimizations + + - Avoid duplication + - Lockless for hot paths + + (*) APPENDIX A: What lockdep does to work aggresively + + (*) APPENDIX B: How to avoid adding false dependencies + + +== +Background +== + +What causes deadlock + + +A deadlock occurs when a context is waiting for an event to happen, +which is impossible because another (or the) context who can trigger the +event is also waiting for another (or the) event to happen, which is +also impossible due to the same reason. + +For example: + + A context going to trigger event C is waiting for event A to happen. + A context going to trigger event A is waiting for event B to happen. + A context going to trigger event B is waiting for event C to happen. + +A deadlock occurs when these three wait operations run at the same time, +because event C cannot be triggered if event A does not happen, which in +turn cannot be triggered if event B does not happen, which in turn +cannot be triggered if event C does not happen. After all, no event can +be triggered since any of them never meets its condition to wake up. + +A dependency might exist between two waiters and a deadlock might happen +due to an incorrect releationship between dependencies. Thus, we must +define what a dependency is first. A dependency exists between them if: + + 1. There are two waiters waiting for each event at a given time. + 2. The only way to wake up each waiter is to trigger its event. + 3. Whether one can be woken up depends on whether the other can. + +Each wait in the example creates its dependency like: + + Event C depends on event A. + Event A depends on event B. + Event B depends on event C. + + NOTE: Precisely speaking, a dependency is one between whether a + waiter for an event can be woken up and whether another waiter for + another event can be woken up. However from now on, we will describe + a dependency as if it's one between an event and another event for + simplicity. + +And they form circular dependencies like: + +-> C -> A -> B - + /\ + \/ + + + where 'A -> B' means that event A depends on event B. + +Such circular dependencies lead to a deadlock since no waiter can meet +its condition to wake up as described. + +CONCLUSION + +Circular dependencies cause a deadlock. + + +How lockdep works +- + +Lockdep tries to detect a deadlock by checking
[PATCH 4/6] mm: Check if mmut notifier callbacks are allowed to fail
Just a bit of paranoia, since if we start pushing this deep into
callchains it's hard to spot all.
Signed-off-by: Daniel Vetter
---
mm/mmu_notifier.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/mm/mmu_notifier.c b/mm/mmu_notifier.c
index 82bb1a939c0e..744840e5636e 100644
--- a/mm/mmu_notifier.c
+++ b/mm/mmu_notifier.c
@@ -190,6 +190,8 @@ int __mmu_notifier_invalidate_range_start(struct mm_struct
*mm,
pr_info("%pS callback failed with %d in
%sblockable context.\n",
mn->ops->invalidate_range_start, _ret,
!blockable ? "non-" : "");
+ WARN(blockable,"%pS callback failure not
allowed\n",
+mn->ops->invalidate_range_start);
ret = _ret;
}
}
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 6/6] mm, notifier: Add a lockdep map for invalidate_range_start
This is a similar idea to the fs_reclaim fake lockdep lock. It's
fairly easy to provoke a specific notifier to be run on a specific
range: Just prep it, and then munmap() it.
A bit harder, but still doable, is to provoke the mmu notifiers for
all the various callchains that might lead to them. But both at the
same time is really hard to reliable hit, especially when you want to
exercise paths like direct reclaim or compaction, where it's not
easy to control what exactly will be unmapped.
By introducing a lockdep map to tie them all together we allow lockdep
to see a lot more dependencies, without having to actually hit them
in a single challchain while testing.
Aside: Since I typed this to test i915 mmu notifiers I've only rolled
this out for the invaliate_range_start callback. If there's
interest, we should probably roll this out to all of them. But my
undestanding of core mm is seriously lacking, and I'm not clear on
whether we need a lockdep map for each callback, or whether some can
be shared.
Signed-off-by: Daniel Vetter
---
include/linux/mmu_notifier.h | 7 +++
mm/mmu_notifier.c| 7 +++
2 files changed, 14 insertions(+)
diff --git a/include/linux/mmu_notifier.h b/include/linux/mmu_notifier.h
index 133ba78820ee..080a9173c7dc 100644
--- a/include/linux/mmu_notifier.h
+++ b/include/linux/mmu_notifier.h
@@ -16,6 +16,10 @@ struct mmu_notifier_ops;
#ifdef CONFIG_MMU_NOTIFIER
+#ifdef CONFIG_LOCKDEP
+extern struct lockdep_map __mmu_notifier_invalidate_range_start_map;
+#endif
+
/*
* The mmu notifier_mm structure is allocated and installed in
* mm->mmu_notifier_mm inside the mm_take_all_locks() protected
@@ -283,8 +287,11 @@ static inline void mmu_notifier_change_pte(struct
mm_struct *mm,
static inline void mmu_notifier_invalidate_range_start(struct mm_struct *mm,
unsigned long start, unsigned long end)
{
+ mutex_acquire(&__mmu_notifier_invalidate_range_start_map, 0, 0,
+ _RET_IP_);
if (mm_has_notifiers(mm))
__mmu_notifier_invalidate_range_start(mm, start, end, true);
+ mutex_release(&__mmu_notifier_invalidate_range_start_map, 1, _RET_IP_);
}
static inline int mmu_notifier_invalidate_range_start_nonblock(struct
mm_struct *mm,
diff --git a/mm/mmu_notifier.c b/mm/mmu_notifier.c
index 4d56e2645b6c..12b917733856 100644
--- a/mm/mmu_notifier.c
+++ b/mm/mmu_notifier.c
@@ -23,6 +23,13 @@
/* global SRCU for all MMs */
DEFINE_STATIC_SRCU(srcu);
+#ifdef CONFIG_LOCKDEP
+struct lockdep_map __mmu_notifier_invalidate_range_start_map = {
+ .name = "mmu_notifier_invalidate_range_start"
+};
+EXPORT_SYMBOL_GPL(__mmu_notifier_invalidate_range_start_map);
+#endif
+
/*
* This function allows mmu_notifier::release callback to delay a call to
* a function that will free appropriate resources. The function must be
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/6] mm, notifier: Catch sleeping/blocking for !blockable
We need to make sure implementations don't cheat and don't have a
possible schedule/blocking point deeply burried where review can't
catch it.
Signed-off-by: Daniel Vetter
---
mm/mmu_notifier.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/mm/mmu_notifier.c b/mm/mmu_notifier.c
index 744840e5636e..4d56e2645b6c 100644
--- a/mm/mmu_notifier.c
+++ b/mm/mmu_notifier.c
@@ -185,7 +185,13 @@ int __mmu_notifier_invalidate_range_start(struct mm_struct
*mm,
id = srcu_read_lock();
hlist_for_each_entry_rcu(mn, >mmu_notifier_mm->list, hlist) {
if (mn->ops->invalidate_range_start) {
- int _ret = mn->ops->invalidate_range_start(mn, mm,
start, end, blockable);
+ int _ret;
+
+ if (IS_ENABLED(CONFIG_DEBUG_ATOMIC_SLEEP) && !blockable)
+ preempt_disable();
+ _ret = mn->ops->invalidate_range_start(mn, mm, start,
end, blockable);
+ if (IS_ENABLED(CONFIG_DEBUG_ATOMIC_SLEEP) && !blockable)
+ preempt_enable();
if (_ret) {
pr_info("%pS callback failed with %d in
%sblockable context.\n",
mn->ops->invalidate_range_start, _ret,
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/6] lockdep: Remove GFP_NOLOCKDEP annotation
This was originally added in 7e7844226f10 ("lockdep: allow to disable
reclaim lockup detection") but a git log -G "GFP_NOLOCKDEP" indicates
it was never used.
Cc: Andrew Morton
Cc: Vlastimil Babka
Cc: Michal Hocko
Cc: Mel Gorman
Cc: Daniel Vetter
Cc: "Levin, Alexander (Sasha Levin)"
Cc: Mike Rapoport
Cc: Huaisheng Ye
Cc: Pavel Tatashin
Cc: Aaron Lu
Cc: Oscar Salvador
Cc: Joonsoo Kim
Cc: linux...@kvack.org
Cc: Dave Chinner
Cc: Peter Zijlstra
Signed-off-by: Daniel Vetter
---
include/linux/gfp.h | 10 +-
mm/page_alloc.c | 3 ---
2 files changed, 1 insertion(+), 12 deletions(-)
diff --git a/include/linux/gfp.h b/include/linux/gfp.h
index 24bcc5eec6b4..7709106d87fd 100644
--- a/include/linux/gfp.h
+++ b/include/linux/gfp.h
@@ -39,11 +39,6 @@ struct vm_area_struct;
#define ___GFP_ACCOUNT 0x10u
#define ___GFP_DIRECT_RECLAIM 0x20u
#define ___GFP_KSWAPD_RECLAIM 0x40u
-#ifdef CONFIG_LOCKDEP
-#define ___GFP_NOLOCKDEP 0x80u
-#else
-#define ___GFP_NOLOCKDEP 0
-#endif
/* If the above are modified, __GFP_BITS_SHIFT may need updating */
/*
@@ -213,11 +208,8 @@ struct vm_area_struct;
#define __GFP_COMP ((__force gfp_t)___GFP_COMP)
#define __GFP_ZERO ((__force gfp_t)___GFP_ZERO)
-/* Disable lockdep for GFP context tracking */
-#define __GFP_NOLOCKDEP ((__force gfp_t)___GFP_NOLOCKDEP)
-
/* Room for N __GFP_FOO bits */
-#define __GFP_BITS_SHIFT (23 + IS_ENABLED(CONFIG_LOCKDEP))
+#define __GFP_BITS_SHIFT 23
#define __GFP_BITS_MASK ((__force gfp_t)((1 << __GFP_BITS_SHIFT) - 1))
/**
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index e2ef1c17942f..b238ab7c1c0d 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -3717,9 +3717,6 @@ static bool __need_fs_reclaim(gfp_t gfp_mask)
if (!(gfp_mask & __GFP_FS))
return false;
- if (gfp_mask & __GFP_NOLOCKDEP)
- return false;
-
return true;
}
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 05/20] drm/meson: Use drm_fbdev_generic_setup()
Den 03.10.2018 21.24, skrev Neil Armstrong:
Hi Noralf,
Le 08/09/2018 15:46, Noralf Trønnes a écrit :
The CMA helper is already using the drm_fb_helper_generic_probe part of
the generic fbdev emulation. This patch makes full use of the generic
fbdev emulation by using its drm_client callbacks. This means that
drm_mode_config_funcs->output_poll_changed and drm_driver->lastclose are
now handled by the emulation code. Additionally fbdev unregister happens
automatically on drm_dev_unregister().
The drm_fbdev_generic_setup() call is put after drm_dev_register() in the
driver. This is done to highlight the fact that fbdev emulation is an
internal client that makes use of the driver, it is not part of the
driver as such. If fbdev setup fails, an error is printed, but the driver
succeeds probing.
Cc: Neil Armstrong
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/meson/meson_drv.c | 19 ++-
drivers/gpu/drm/meson/meson_drv.h | 1 -
2 files changed, 2 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/meson/meson_drv.c
b/drivers/gpu/drm/meson/meson_drv.c
index d3443125e661..348b5a198b9d 100644
--- a/drivers/gpu/drm/meson/meson_drv.c
+++ b/drivers/gpu/drm/meson/meson_drv.c
@@ -68,15 +68,7 @@
* - Powering Up HDMI controller and PHY
*/
-static void meson_fb_output_poll_changed(struct drm_device *dev)
-{
- struct meson_drm *priv = dev->dev_private;
-
- drm_fbdev_cma_hotplug_event(priv->fbdev);
-}
-
static const struct drm_mode_config_funcs meson_mode_config_funcs = {
- .output_poll_changed = meson_fb_output_poll_changed,
.atomic_check= drm_atomic_helper_check,
.atomic_commit = drm_atomic_helper_commit,
.fb_create = drm_gem_fb_create,
@@ -282,13 +274,6 @@ static int meson_drv_bind_master(struct device *dev, bool
has_components)
drm_mode_config_reset(drm);
- priv->fbdev = drm_fbdev_cma_init(drm, 32,
-drm->mode_config.num_connector);
- if (IS_ERR(priv->fbdev)) {
- ret = PTR_ERR(priv->fbdev);
- goto free_drm;
- }
-
drm_kms_helper_poll_init(drm);
platform_set_drvdata(pdev, priv);
@@ -297,6 +282,8 @@ static int meson_drv_bind_master(struct device *dev, bool
has_components)
if (ret)
goto free_drm;
+ drm_fbdev_generic_setup(drm, 32);
+
return 0;
free_drm:
@@ -313,11 +300,9 @@ static int meson_drv_bind(struct device *dev)
static void meson_drv_unbind(struct device *dev)
{
struct drm_device *drm = dev_get_drvdata(dev);
- struct meson_drm *priv = drm->dev_private;
drm_dev_unregister(drm);
drm_kms_helper_poll_fini(drm);
- drm_fbdev_cma_fini(priv->fbdev);
drm_mode_config_cleanup(drm);
drm_dev_put(drm);
diff --git a/drivers/gpu/drm/meson/meson_drv.h b/drivers/gpu/drm/meson/meson_drv.h
index 8450d6ac8c9b..aab96260da9f 100644
--- a/drivers/gpu/drm/meson/meson_drv.h
+++ b/drivers/gpu/drm/meson/meson_drv.h
@@ -33,7 +33,6 @@ struct meson_drm {
struct drm_device *drm;
struct drm_crtc *crtc;
- struct drm_fbdev_cma *fbdev;
struct drm_plane *primary_plane;
/* Components Data */
A little bit late to get this in 4.20 (or 5.0) and get rid of the old fbdev
code,
but at least we have a (dirty) workaround in place for the Mali fbdev blob...
Glad you found a solution for that!
Acked-by: Neil Armstrong
Thanks for pushing the fbdev emulation on the right path !
Applied to drm-misc-next, thanks.
Noralf.
Neil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 14/20] drm/stm: Use drm_fbdev_generic_setup()
Den 27.09.2018 13.45, skrev Yannick FERTRE:
Hi Noralf,
many thanks for your patch.
Acked-by: Yannick Fertré
Applied to drm-misc-next, thanks.
Noralf.
On 09/08/2018 03:46 PM, Noralf Trønnes wrote:
The CMA helper is already using the drm_fb_helper_generic_probe part of
the generic fbdev emulation. This patch makes full use of the generic
fbdev emulation by using its drm_client callbacks. This means that
drm_mode_config_funcs->output_poll_changed and drm_driver->lastclose are
now handled by the emulation code. Additionally fbdev unregister happens
automatically on drm_dev_unregister().
The drm_fbdev_generic_setup() call is put after drm_dev_register() in the
driver. This is done to highlight the fact that fbdev emulation is an
internal client that makes use of the driver, it is not part of the
driver as such. If fbdev setup fails, an error is printed, but the driver
succeeds probing.
drm_fbdev_generic_setup() handles mode_config.num_connector being zero.
In that case it retries fbdev setup on the next .output_poll_changed.
Cc: Yannick Fertre
Cc: Philippe Cornu
Cc: Benjamin Gaignard
Cc: Vincent Abriou
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/stm/drv.c | 11 ++-
1 file changed, 2 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/stm/drv.c b/drivers/gpu/drm/stm/drv.c
index f2021b23554d..97eee8660014 100644
--- a/drivers/gpu/drm/stm/drv.c
+++ b/drivers/gpu/drm/stm/drv.c
@@ -26,7 +26,6 @@
static const struct drm_mode_config_funcs drv_mode_config_funcs = {
.fb_create = drm_gem_fb_create,
- .output_poll_changed = drm_fb_helper_output_poll_changed,
.atomic_check = drm_atomic_helper_check,
.atomic_commit = drm_atomic_helper_commit,
};
@@ -52,7 +51,6 @@ DEFINE_DRM_GEM_CMA_FOPS(drv_driver_fops);
static struct drm_driver drv_driver = {
.driver_features = DRIVER_MODESET | DRIVER_GEM | DRIVER_PRIME |
DRIVER_ATOMIC,
- .lastclose = drm_fb_helper_lastclose,
.name = "stm",
.desc = "STMicroelectronics SoC DRM",
.date = "20170330",
@@ -108,12 +106,6 @@ static int drv_load(struct drm_device *ddev)
drm_mode_config_reset(ddev);
drm_kms_helper_poll_init(ddev);
- if (ddev->mode_config.num_connector) {
- ret = drm_fb_cma_fbdev_init(ddev, 16, 0);
- if (ret)
- DRM_DEBUG("Warning: fails to create fbdev\n");
- }
-
platform_set_drvdata(pdev, ddev);
return 0;
@@ -126,7 +118,6 @@ static void drv_unload(struct drm_device *ddev)
{
DRM_DEBUG("%s\n", __func__);
- drm_fb_cma_fbdev_fini(ddev);
drm_kms_helper_poll_fini(ddev);
ltdc_unload(ddev);
drm_mode_config_cleanup(ddev);
@@ -154,6 +145,8 @@ static int stm_drm_platform_probe(struct platform_device
*pdev)
if (ret)
goto err_put;
+ drm_fbdev_generic_setup(ddev, 16);
+
return 0;
err_put:
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] drm: fix call_kern.cocci warnings v3
Give this a nice summary,
drm/syncobj: Avoid kmalloc(GFP_KERNEL) under spinlock
Quoting Chunming Zhou (2018-10-25 11:21:05)
> drivers/gpu/drm/drm_syncobj.c:202:4-14: ERROR: function
> drm_syncobj_find_signal_pt_for_point called on line 390 inside lock on line
> 389 but uses GFP_KERNEL
>
> Find functions that refer to GFP_KERNEL but are called with locks held.
>
> Generated by: scripts/coccinelle/locks/call_kern.cocci
>
> v2:
> syncobj->timeline still needs protect.
>
> v3:
> use a global signaled fence instead of re-allocation.
>
Good practice, would be to add Testcase: (and as penance for the bug,
write it ;)
> Signed-off-by: Chunming Zhou
> Cc: Maarten Lankhorst
> Cc: intel-...@lists.freedesktop.org
> Cc: Christian König
> ---
> drivers/gpu/drm/drm_drv.c | 2 ++
> drivers/gpu/drm/drm_syncobj.c | 52 +--
> include/drm/drm_syncobj.h | 1 +
> 3 files changed, 34 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index 36e8e9cbec52..0a6f1023d6c3 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -37,6 +37,7 @@
> #include
> #include
> #include
> +#include
>
> #include "drm_crtc_internal.h"
> #include "drm_legacy.h"
> @@ -1003,6 +1004,7 @@ static int __init drm_core_init(void)
> if (ret < 0)
> goto error;
>
> + drm_syncobj_stub_fence_init();
> drm_core_init_complete = true;
>
> DRM_DEBUG("Initialized\n");
> diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
> index b7eaa603f368..6b3f5a06e4d3 100644
> --- a/drivers/gpu/drm/drm_syncobj.c
> +++ b/drivers/gpu/drm/drm_syncobj.c
> @@ -80,6 +80,27 @@ struct drm_syncobj_signal_pt {
> struct list_head list;
> };
>
> +static struct drm_syncobj_stub_fence stub_signaled_fence;
> +static void global_stub_fence_release(struct dma_fence *fence)
> +{
> + /* it is impossible to come here */
> + BUG();
BUG() is overkill, kasan will complain for us anyway, so we can just use
the default release function.
> +}
> +static const struct dma_fence_ops global_stub_fence_ops = {
> + .get_driver_name = drm_syncobj_stub_fence_get_name,
> + .get_timeline_name = drm_syncobj_stub_fence_get_name,
> + .release = global_stub_fence_release,
> +};
> +
> +void drm_syncobj_stub_fence_init(void)
I think we can avoid having this exposed by:
static DECLARE_SPINLOCK(signaled_fence_lock);
static dma_fence signaled_fence;
static struct dma_fence *signaled_fence_get(void)
{
spin_lock(_fenced_lock);
if (!signaled_fence.ops) {
dma_fence_init(_fence,
_fence_ops,
_fence_lock,
0, 0);
dma_fence_signal_locked(_fence.base);
}
spin_unlock(_fenced_lock);
return dma_fence_get(_fence);
}
> /**
> * drm_syncobj_find - lookup and reference a sync object.
> * @file_private: drm file private pointer
> @@ -111,24 +132,14 @@ static struct dma_fence
> uint64_t point)
> {
> struct drm_syncobj_signal_pt *signal_pt;
> + struct dma_fence *f = NULL;
>
> + spin_lock(>pt_lock);
> if ((syncobj->type == DRM_SYNCOBJ_TYPE_TIMELINE) &&
> (point <= syncobj->timeline)) {
> - struct drm_syncobj_stub_fence *fence =
> - kzalloc(sizeof(struct drm_syncobj_stub_fence),
> - GFP_KERNEL);
> -
> - if (!fence)
> - return NULL;
> - spin_lock_init(>lock);
> - dma_fence_init(>base,
> - _syncobj_stub_fence_ops,
> - >lock,
> - syncobj->timeline_context,
> - point);
> -
> - dma_fence_signal(>base);
> - return >base;
> + dma_fence_get(_signaled_fence.base);
> + spin_unlock(>pt_lock);
> + return _signaled_fence.base;
f = signaled_fence_get();
goto unlock;
> }
>
> list_for_each_entry(signal_pt, >signal_pt_list, list) {
> @@ -137,9 +148,12 @@ static struct dma_fence
> if ((syncobj->type == DRM_SYNCOBJ_TYPE_BINARY) &&
> (point != signal_pt->value))
> continue;
> - return dma_fence_get(_pt->fence_array->base);
> + f = dma_fence_get(_pt->fence_array->base);
> + break;
> }
> - return NULL;
unlock:
> + spin_unlock(>pt_lock);
> +
> + return f;
> }
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107333] Display Not Detected If Powered Off When amdgpu.dc=1
https://bugs.freedesktop.org/show_bug.cgi?id=107333 --- Comment #4 from Benjamin Hodgetts --- To anyone checking, this is still an issue with versions: Kernel 4.18.16, LLVM 8.0.0, Mesa 18.3.0-devel, XOrg 1.20.2. Monitor is connected, but powered off: Screen 0: minimum 320 x 200, current 1024 x 768, maximum 16384 x 16384 DisplayPort-0 disconnected primary (normal left inverted right x axis y axis) DisplayPort-1 disconnected (normal left inverted right x axis y axis) HDMI-A-0 disconnected (normal left inverted right x axis y axis) HDMI-A-1 disconnected (normal left inverted right x axis y axis) DVI-D-0 disconnected (normal left inverted right x axis y axis) -- 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 108521] RX 580 as eGPU amdgpu: gpu post error!
https://bugs.freedesktop.org/show_bug.cgi?id=108521 Robert Strube changed: What|Removed |Added Attachment #142200|lspci (no eGPU) |lspci with eGPU *not* description||connected. -- 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 108521] RX 580 as eGPU amdgpu: gpu post error!
https://bugs.freedesktop.org/show_bug.cgi?id=108521 --- Comment #16 from Robert Strube --- Created attachment 142202 --> https://bugs.freedesktop.org/attachment.cgi?id=142202=edit fresh dmesg log booting system *without* eGPU -- 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: fix call_kern.cocci warnings v3
Am 25.10.18 um 12:36 schrieb Maarten Lankhorst:
> Op 25-10-18 om 12:21 schreef Chunming Zhou:
>> drivers/gpu/drm/drm_syncobj.c:202:4-14: ERROR: function
>> drm_syncobj_find_signal_pt_for_point called on line 390 inside lock on line
>> 389 but uses GFP_KERNEL
>>
>>Find functions that refer to GFP_KERNEL but are called with locks held.
>>
>> Generated by: scripts/coccinelle/locks/call_kern.cocci
>>
>> v2:
>> syncobj->timeline still needs protect.
>>
>> v3:
>> use a global signaled fence instead of re-allocation.
>>
>> Signed-off-by: Chunming Zhou
>> Cc: Maarten Lankhorst
>> Cc: intel-...@lists.freedesktop.org
>> Cc: Christian König
>> ---
>> drivers/gpu/drm/drm_drv.c | 2 ++
>> drivers/gpu/drm/drm_syncobj.c | 52 +--
>> include/drm/drm_syncobj.h | 1 +
>> 3 files changed, 34 insertions(+), 21 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
>> index 36e8e9cbec52..0a6f1023d6c3 100644
>> --- a/drivers/gpu/drm/drm_drv.c
>> +++ b/drivers/gpu/drm/drm_drv.c
>> @@ -37,6 +37,7 @@
>> #include
>> #include
>> #include
>> +#include
>>
>> #include "drm_crtc_internal.h"
>> #include "drm_legacy.h"
>> @@ -1003,6 +1004,7 @@ static int __init drm_core_init(void)
>> if (ret < 0)
>> goto error;
>>
>> +drm_syncobj_stub_fence_init();
>> drm_core_init_complete = true;
>>
>> DRM_DEBUG("Initialized\n");
>> diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
>> index b7eaa603f368..6b3f5a06e4d3 100644
>> --- a/drivers/gpu/drm/drm_syncobj.c
>> +++ b/drivers/gpu/drm/drm_syncobj.c
>> @@ -80,6 +80,27 @@ struct drm_syncobj_signal_pt {
>> struct list_head list;
>> };
>>
>> +static struct drm_syncobj_stub_fence stub_signaled_fence;
>> +static void global_stub_fence_release(struct dma_fence *fence)
>> +{
>> +/* it is impossible to come here */
>> +BUG();
>> +}
> WARN_ON_ONCE(1)? No need to halt the machine.
>
>> +static const struct dma_fence_ops global_stub_fence_ops = {
>> +.get_driver_name = drm_syncobj_stub_fence_get_name,
>> +.get_timeline_name = drm_syncobj_stub_fence_get_name,
>> +.release = global_stub_fence_release,
>> +};
>> +
>> +void drm_syncobj_stub_fence_init(void)
>> +{
>> +spin_lock_init(_signaled_fence.lock);
>> +dma_fence_init(_signaled_fence.base,
>> + _stub_fence_ops,
>> + _signaled_fence.lock,
>> + 0, 0);
>> +dma_fence_signal(_signaled_fence.base);
>> +}
>> /**
>>* drm_syncobj_find - lookup and reference a sync object.
>>* @file_private: drm file private pointer
>> @@ -111,24 +132,14 @@ static struct dma_fence
>>uint64_t point)
>> {
>> struct drm_syncobj_signal_pt *signal_pt;
>> +struct dma_fence *f = NULL;
>>
>> +spin_lock(>pt_lock);
>> if ((syncobj->type == DRM_SYNCOBJ_TYPE_TIMELINE) &&
>> (point <= syncobj->timeline)) {
>> -struct drm_syncobj_stub_fence *fence =
>> -kzalloc(sizeof(struct drm_syncobj_stub_fence),
>> -GFP_KERNEL);
>> -
>> -if (!fence)
>> -return NULL;
>> -spin_lock_init(>lock);
>> -dma_fence_init(>base,
>> - _syncobj_stub_fence_ops,
>> - >lock,
>> - syncobj->timeline_context,
>> - point);
>> -
>> -dma_fence_signal(>base);
>> -return >base;
>> +dma_fence_get(_signaled_fence.base);
>> +spin_unlock(>pt_lock);
>> +return _signaled_fence.base;
>> }
>>
>> list_for_each_entry(signal_pt, >signal_pt_list, list) {
>> @@ -137,9 +148,12 @@ static struct dma_fence
>> if ((syncobj->type == DRM_SYNCOBJ_TYPE_BINARY) &&
>> (point != signal_pt->value))
>> continue;
>> -return dma_fence_get(_pt->fence_array->base);
>> +f = dma_fence_get(_pt->fence_array->base);
>> +break;
>> }
>> -return NULL;
>> +spin_unlock(>pt_lock);
>> +
>> +return f;
>> }
>>
>> static void drm_syncobj_add_callback_locked(struct drm_syncobj *syncobj,
>> @@ -166,9 +180,7 @@ static void drm_syncobj_fence_get_or_add_callback(struct
>> drm_syncobj *syncobj,
>> }
>>
>> mutex_lock(>cb_mutex);
>> -spin_lock(>pt_lock);
>> *fence = drm_syncobj_find_signal_pt_for_point(syncobj, pt_value);
>> -spin_unlock(>pt_lock);
>> if (!*fence)
>> drm_syncobj_add_callback_locked(syncobj, cb, func);
>> mutex_unlock(>cb_mutex);
>> @@ -379,11 +391,9 @@ drm_syncobj_point_get(struct drm_syncobj *syncobj, u64
>> point, u64 flags,
>> if (ret < 0)
>> return ret;
>> }
>> -spin_lock(>pt_lock);
>> *fence = drm_syncobj_find_signal_pt_for_point(syncobj,
Re: [PATCH] RFC: Make igts for cross-driver stuff mandatory?
On Fri, Oct 19, 2018 at 10:50:49AM +0200, Daniel Vetter wrote:
> Hi all,
>
> This is just to collect feedback on this idea, and see whether the
> overall dri-devel community stands on all this. I think the past few
> cross-vendor uapi extensions all came with igts attached, and
> personally I think there's lots of value in having them: A
> cross-vendor interface isn't useful if every driver implements it
> slightly differently.
>
> I think there's 2 questions here:
>
> - Do we want to make such testcases mandatory?
>
Yes, more testing == better code.
> - If yes, are we there yet, or is there something crucially missing
> still?
In my experience, no. Last week while trying to replicate an intel-gfx CI
failure, I tried compiling igt for one of my (intel) chromebooks. It seems like
cross-compilation (or, in my case, just specifying
prefix/ld_library_path/sbin_path) is broken on igt. If we want to impose
restrictions across the entire subsystem, we need to make sure that everyone can
build and deploy igt easily.
I managed to hack around everything and get it working, but I still haven't
tried switching out the toolchain. Once we have some GitLab CI to validate
cross-compilation, then we can consider making IGT mandatory.
It's possible that I'm just a meson n00b and didn't use the right incantation,
so maybe it already works, but then we need better documentation.
I've pasted my horrible hacks below, I also didn't have libunwind, so removed
its usage.
Sean
/snip
From ab8c7d274c32559295b38d6ceeaabded14b207d4 Mon Sep 17 00:00:00 2001
From: Sean Paul
Date: Thu, 25 Oct 2018 08:40:28 -0400
Subject: [PATCH] igt: Hacks to compile in CrOS chroot
Signed-off-by: Sean Paul
---
lib/igt_core.c| 78 ---
lib/meson.build | 1 -
meson.build | 4 +-
tests/gem_userptr_blits.c | 2 +
tools/meson.build | 7
5 files changed, 5 insertions(+), 87 deletions(-)
diff --git a/lib/igt_core.c b/lib/igt_core.c
index 23bb858f..ca65d7cc 100644
--- a/lib/igt_core.c
+++ b/lib/igt_core.c
@@ -71,8 +71,6 @@
#include "igt_sysrq.h"
#include "igt_rc.h"
-#define UNW_LOCAL_ONLY
-#include
#include
#ifdef HAVE_LIBGEN_H
@@ -1209,63 +1207,6 @@ static void write_stderr(const char *str)
static void print_backtrace(void)
{
- unw_cursor_t cursor;
- unw_context_t uc;
- int stack_num = 0;
-
- Dwfl_Callbacks cbs = {
- .find_elf = dwfl_linux_proc_find_elf,
- .find_debuginfo = dwfl_standard_find_debuginfo,
- };
-
- Dwfl *dwfl = dwfl_begin();
-
- if (dwfl_linux_proc_report(dwfl, getpid())) {
- dwfl_end(dwfl);
- dwfl = NULL;
- } else
- dwfl_report_end(dwfl, NULL, NULL);
-
- igt_info("Stack trace:\n");
-
- unw_getcontext();
- unw_init_local(, );
- while (unw_step() > 0) {
- char name[255];
- unw_word_t off, ip;
- Dwfl_Module *mod = NULL;
-
- unw_get_reg(, UNW_REG_IP, );
-
- if (dwfl)
- mod = dwfl_addrmodule(dwfl, ip);
-
- if (mod) {
- const char *src, *dwfl_name;
- Dwfl_Line *line;
- int lineno;
- GElf_Sym sym;
-
- line = dwfl_module_getsrc(mod, ip);
- dwfl_name = dwfl_module_addrsym(mod, ip, , NULL);
-
- if (line && dwfl_name) {
- src = dwfl_lineinfo(line, NULL, , NULL,
NULL, NULL);
- igt_info(" #%d %s:%d %s()\n", stack_num++,
src, lineno, dwfl_name);
- continue;
- }
- }
-
- if (unw_get_proc_name(, name, 255, ) < 0)
- igt_info(" #%d [+0x%x]\n", stack_num++,
-(unsigned int) ip);
- else
- igt_info(" #%d [%s+0x%x]\n", stack_num++, name,
-(unsigned int) off);
- }
-
- if (dwfl)
- dwfl_end(dwfl);
}
static const char hex[] = "0123456789abcdef";
@@ -1420,25 +1361,6 @@ xprintf(const char *fmt, ...)
static void print_backtrace_sig_safe(void)
{
- unw_cursor_t cursor;
- unw_context_t uc;
- int stack_num = 0;
-
- write_stderr("Stack trace: \n");
-
- unw_getcontext();
- unw_init_local(, );
- while (unw_step() > 0) {
- char name[255];
- unw_word_t off;
-
- if (unw_get_proc_name(, name, 255, ) < 0)
- xstrlcpy(name, "", 10);
-
- xprintf(" #%d [%s+0x%x]\n", stack_num++, name,
- (unsigned int) off);
-
- }
}
void __igt_fail_assert(const char *domain, const char *file, const int line,
diff --git a/lib/meson.build
Re: [PATCH libdrm 1/2] xf86drm: fallback to DRIVER uevent entry when OF_FULLNAME fails
On Thu, 18 Oct 2018 at 21:07, Christian Gmeiner wrote: > > Signed-off-by: Christian Gmeiner > --- > xf86drm.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/xf86drm.c b/xf86drm.c > index 10df682b..4ee1337b 100644 > --- a/xf86drm.c > +++ b/xf86drm.c > @@ -3516,6 +3516,8 @@ static int drmParsePlatformBusInfo(int maj, int min, > drmPlatformBusInfoPtr info) > snprintf(path, sizeof(path), "/sys/dev/char/%d:%d/device", maj, min); > > name = sysfs_uevent_get(path, "OF_FULLNAME"); > +if (!name) > +name = sysfs_uevent_get(path, "DRIVER"); This workaround will work for etnaviv, but not for all platform devices. Personally, I'd recommend reverting the Mesa patch for now... I'm checking with some kernel-savvy people how we can resolve thing properly. -Emil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH] drm/scheduler: Add drm_sched_job_cleanup
Am 24.10.18 um 16:55 schrieb Jordan Crouse:
> On Wed, Oct 24, 2018 at 07:10:23PM +0530, Sharat Masetty wrote:
>> Hi,
>>
>> Can you please review this and share your thoughts on this approach. We
>> primarily need a clean way to release the finished fence in case the job
>> was not pushed to the queue. So, this patch adds the new API to clean up
>> the resources allocated in sched_job_init()
>>
>> Additionally I also move the fence_put(finished_fence) from the
>> scheduler to the drivers handler of free_job(). The drivers get to use
>> this new API. This is done so that the layer creating the sched object is
>> the one freeing up the resources as well.
>>
>> Signed-off-by: Sharat Masetty
>> ---
>> drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c| 2 +-
>> drivers/gpu/drm/amd/amdgpu/amdgpu_job.c | 2 ++
>> drivers/gpu/drm/etnaviv/etnaviv_sched.c | 2 ++
>> drivers/gpu/drm/msm/msm_sched.c | 8 +++-
> Just a nit - msm_sched.c isn't a thing yet. Can you re-generate a patch
> against
> drm-next so that if folks like this they can get it merged sooner?
Not a bad idea, but first of all as Jordan commented please rebase this
on drm-next maybe even Alex amd-staging-drm-next branch.
Additional to that you missed one more occurrence where this needs to be
applied in amdgpu_cs_submit().
Regards,
Christian.
>
> Jordan
>> drivers/gpu/drm/scheduler/gpu_scheduler.c | 11 +--
>> drivers/gpu/drm/v3d/v3d_sched.c | 2 ++
>> include/drm/gpu_scheduler.h | 1 +
>> 7 files changed, 20 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
>> index 9c85a90..9a83152 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
>> @@ -1198,7 +1198,7 @@ static int amdgpu_cs_submit(struct amdgpu_cs_parser *p,
>> r = amdgpu_ctx_add_fence(p->ctx, ring, p->fence, );
>> if (r) {
>> dma_fence_put(p->fence);
>> -dma_fence_put(>base.s_fence->finished);
>> +drm_sched_job_cleanup(>base);
>> amdgpu_job_free(job);
>> amdgpu_mn_unlock(p->mn);
>> return r;
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
>> index 2bd5676..5d252d4 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
>> @@ -100,6 +100,8 @@ static void amdgpu_job_free_cb(struct drm_sched_job
>> *s_job)
>> {
>> struct amdgpu_job *job = container_of(s_job, struct amdgpu_job, base);
>>
>> +drm_sched_job_cleanup(s_job);
>> +
>> amdgpu_ring_priority_put(job->ring, s_job->s_priority);
>> dma_fence_put(job->fence);
>> amdgpu_sync_free(>sync);
>> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_sched.c
>> b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
>> index 50d6b88..30398c5 100644
>> --- a/drivers/gpu/drm/etnaviv/etnaviv_sched.c
>> +++ b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
>> @@ -127,6 +127,8 @@ static void etnaviv_sched_free_job(struct drm_sched_job
>> *sched_job)
>> {
>> struct etnaviv_gem_submit *submit = to_etnaviv_submit(sched_job);
>>
>> +drm_sched_job_cleanup(sched_job);
>> +
>> etnaviv_submit_put(submit);
>> }
>>
>> diff --git a/drivers/gpu/drm/msm/msm_sched.c
>> b/drivers/gpu/drm/msm/msm_sched.c
>> index 70b7713..748acc6 100644
>> --- a/drivers/gpu/drm/msm/msm_sched.c
>> +++ b/drivers/gpu/drm/msm/msm_sched.c
>> @@ -235,6 +235,8 @@ static void msm_sched_free_job(struct drm_sched_job
>> *sched_job)
>> struct msm_gpu *gpu = submit->gpu;
>> int i;
>>
>> +drm_sched_job_cleanup(sched_job);
>> +
>> mutex_lock(>dev->struct_mutex);
>>
>> for (i = 0; i < submit->nr_bos; i++) {
>> @@ -300,11 +302,7 @@ int msm_sched_job_init(struct drm_sched_job *sched_job)
>> mutex_unlock(>fence_idr_lock);
>>
>> if (submit->out_fence_id < 0) {
>> -/*
>> - * TODO: The scheduler's finished fence leaks here since the
>> - * job will not be pushed to the queue. Need to update scheduler
>> - * to fix this cleanly(?)
>> - */
>> +drm_sched_job_cleanup(sched_job);
>> dma_fence_put(submit->out_fence);
>> submit->out_fence = NULL;
>> return -ENOMEM;
>> diff --git a/drivers/gpu/drm/scheduler/gpu_scheduler.c
>> b/drivers/gpu/drm/scheduler/gpu_scheduler.c
>> index f5534ff..bbf9315 100644
>> --- a/drivers/gpu/drm/scheduler/gpu_scheduler.c
>> +++ b/drivers/gpu/drm/scheduler/gpu_scheduler.c
>> @@ -214,7 +214,6 @@ static void drm_sched_entity_kill_jobs_cb(struct
>> dma_fence *f,
>> finish_cb);
>> drm_sched_fence_finished(job->s_fence);
>> WARN_ON(job->s_fence->parent);
>> -dma_fence_put(>s_fence->finished);
>> job->sched->ops->free_job(job);
>> }
>>
>> @@ -480,7 +479,6 @@ static
[Bug 108318] [Polaris] Glitches in New Super Mario Brothers U in Cemu on Polaris and Tahiti (maybe more)
https://bugs.freedesktop.org/show_bug.cgi?id=108318 --- Comment #9 from John Galt --- R600_DEBUG=nir works around this issue. If requested, I can provide apidoc of this rendering 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 108521] RX 580 as eGPU amdgpu: gpu post error!
https://bugs.freedesktop.org/show_bug.cgi?id=108521 --- Comment #14 from Robert Strube --- Created attachment 142200 --> https://bugs.freedesktop.org/attachment.cgi?id=142200=edit lspci (no eGPU) lspci -t -nn -v output when the eGPU is *not* connected. -- 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 v6 22/28] drm/i915/dp: Populate DSC PPS SDP and send PPS infoframes
On Wed, Oct 24, 2018 at 03:28:34PM -0700, Manasi Navare wrote:
> DSC PPS secondary data packet infoframes are filled with
> DSC picure parameter set metadata according to the DSC standard.
> These infoframes are sent to the sink device and used during DSC
> decoding.
>
> v2:
> * Rebase ond drm-tip
>
> Cc: Jani Nikula
> Cc: Ville Syrjala
> Cc: Anusha Srivatsa
> Signed-off-by: Manasi Navare
> Reviewed-by: Anusha Srivatsa
> ---
> drivers/gpu/drm/i915/intel_vdsc.c | 21 +
> 1 file changed, 21 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_vdsc.c
> b/drivers/gpu/drm/i915/intel_vdsc.c
> index b0fc716bbbfd..4b4b812d68f3 100644
> --- a/drivers/gpu/drm/i915/intel_vdsc.c
> +++ b/drivers/gpu/drm/i915/intel_vdsc.c
> @@ -988,6 +988,25 @@ static void intel_configure_pps_for_dsc_encoder(struct
> intel_encoder *encoder,
> }
> }
>
> +static void intel_dp_send_dsc_pps_sdp(struct intel_encoder *encoder,
> + struct intel_crtc_state *crtc_state)
const crtc_state
s/send/write/ ?
> +{
> + struct intel_dp *intel_dp = enc_to_intel_dp(>base);
> + struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
> + struct drm_dsc_config *vdsc_cfg = _state->dp_dsc_cfg;
> + struct drm_dsc_pps_infoframe dp_dsc_pps_sdp;
> +
> + /* Prepare DP SDP PPS header as per DP 1.4 spec, Table 2-123 */
> + drm_dsc_dp_pps_header_init(_dsc_pps_sdp);
> +
> + /* Fill the PPS payload bytes as per DSC spec 1.2 Table 4-1 */
> + drm_dsc_pps_infoframe_pack(_dsc_pps_sdp, vdsc_cfg);
> +
> + intel_dig_port->write_infoframe(encoder, crtc_state,
> + DP_SDP_PPS, _dsc_pps_sdp,
> + sizeof(dp_dsc_pps_sdp));
> +}
> +
> void intel_dsc_enable(struct intel_encoder *encoder,
> struct intel_crtc_state *crtc_state)
> {
> @@ -997,5 +1016,7 @@ void intel_dsc_enable(struct intel_encoder *encoder,
>
> intel_configure_pps_for_dsc_encoder(encoder, crtc_state);
>
> + intel_dp_send_dsc_pps_sdp(encoder, crtc_state);
> +
> return;
> }
> --
> 2.18.0
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 21/28] drm/i915/dp: Use the existing write_infoframe() for DSC PPS SDPs
On Wed, Oct 24, 2018 at 03:28:33PM -0700, Manasi Navare wrote:
> Infoframes are used to send secondary data packets. This patch
> adds support for DSC Picture parameter set secondary data packets
> in the existing write_infoframe helpers.
>
> v2:
> * Rebase on drm-tip (Manasi)
>
> Cc: Jani Nikula
> Cc: Ville Syrjala
> Cc: Anusha Srivatsa
> Signed-off-by: Manasi Navare
> Reviewed-by: Anusha Srivatsa
> ---
> drivers/gpu/drm/i915/i915_reg.h | 1 +
> drivers/gpu/drm/i915/intel_hdmi.c | 23 +--
> 2 files changed, 22 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 64cca0a83cf7..0ecdc95f56d8 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -4545,6 +4545,7 @@ enum {
> * of the infoframe structure specified by CEA-861. */
> #define VIDEO_DIP_DATA_SIZE32
> #define VIDEO_DIP_VSC_DATA_SIZE36
> +#define VIDEO_DIP_PPS_DATA_SIZE132
> #define VIDEO_DIP_CTL_MMIO(0x61170)
> /* Pre HSW: */
> #define VIDEO_DIP_ENABLE (1 << 31)
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index d3e653640ce7..02fb54737d92 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -115,6 +115,8 @@ static u32 hsw_infoframe_enable(unsigned int type)
> switch (type) {
> case DP_SDP_VSC:
> return VIDEO_DIP_ENABLE_VSC_HSW;
> + case DP_SDP_PPS:
> + return VDIP_ENABLE_PPS;
Hmm. Why is that bit named so differently to the rest?
> case HDMI_INFOFRAME_TYPE_AVI:
> return VIDEO_DIP_ENABLE_AVI_HSW;
> case HDMI_INFOFRAME_TYPE_SPD:
> @@ -136,6 +138,8 @@ hsw_dip_data_reg(struct drm_i915_private *dev_priv,
> switch (type) {
> case DP_SDP_VSC:
> return HSW_TVIDEO_DIP_VSC_DATA(cpu_transcoder, i);
> + case DP_SDP_PPS:
> + return ICL_VIDEO_DIP_PPS_DATA(cpu_transcoder, i);
> case HDMI_INFOFRAME_TYPE_AVI:
> return HSW_TVIDEO_DIP_AVI_DATA(cpu_transcoder, i);
> case HDMI_INFOFRAME_TYPE_SPD:
> @@ -148,6 +152,18 @@ hsw_dip_data_reg(struct drm_i915_private *dev_priv,
> }
> }
>
> +static int hsw_dip_data_size(unsigned int type)
> +{
> + switch (type) {
> + case DP_SDP_VSC:
> + return VIDEO_DIP_VSC_DATA_SIZE;
> + case DP_SDP_PPS:
> + return VIDEO_DIP_PPS_DATA_SIZE;
> + default:
> + return VIDEO_DIP_DATA_SIZE;
> + }
> +}
> +
> static void g4x_write_infoframe(struct intel_encoder *encoder,
> const struct intel_crtc_state *crtc_state,
> unsigned int type,
> @@ -382,11 +398,14 @@ static void hsw_write_infoframe(struct intel_encoder
> *encoder,
> struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
> i915_reg_t ctl_reg = HSW_TVIDEO_DIP_CTL(cpu_transcoder);
> - int data_size = type == DP_SDP_VSC ?
> - VIDEO_DIP_VSC_DATA_SIZE : VIDEO_DIP_DATA_SIZE;
> + i915_reg_t data_reg;
> + int data_size = 0;
=0 is unnecessary.
> int i;
> u32 val = I915_READ(ctl_reg);
>
> + data_size = hsw_dip_data_size(type);
> + data_reg = hsw_dip_data_reg(dev_priv, cpu_transcoder, type, 0);
data_reg is unused.
> +
> val &= ~hsw_infoframe_enable(type);
> I915_WRITE(ctl_reg, val);
>
> --
> 2.18.0
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 24/28] drm/i915/dp: Configure Display stream splitter registers during DSC enable
On Wed, Oct 24, 2018 at 03:28:36PM -0700, Manasi Navare wrote:
> Display Stream Splitter registers need to be programmed to enable
> the joiner if two DSC engines are used and also to enable
> the left and the right DSC engines. This happens as part of
> the DSC enabling routine in the source in atomic commit.
>
> v3:
> * Use cpu_transcoder instead of encoder->type (Ville)
> v2:
> * Rebase (Manasi)
>
> Cc: Jani Nikula
> Cc: Ville Syrjala
> Cc: Anusha Srivatsa
> Signed-off-by: Manasi Navare
> Reviewed-by: Anusha Srivatsa
> ---
> drivers/gpu/drm/i915/intel_vdsc.c | 22 ++
> 1 file changed, 22 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_vdsc.c
> b/drivers/gpu/drm/i915/intel_vdsc.c
> index 4b4b812d68f3..8b46619aae15 100644
> --- a/drivers/gpu/drm/i915/intel_vdsc.c
> +++ b/drivers/gpu/drm/i915/intel_vdsc.c
> @@ -1010,6 +1010,12 @@ static void intel_dp_send_dsc_pps_sdp(struct
> intel_encoder *encoder,
> void intel_dsc_enable(struct intel_encoder *encoder,
> struct intel_crtc_state *crtc_state)
> {
> + struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
> + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> + enum pipe pipe = crtc->pipe;
> + i915_reg_t dss_ctl1_reg, dss_ctl2_reg;
> + u32 dss_ctl1_val = 0;
> + u32 dss_ctl2_val = 0;
>
> if (!crtc_state->dsc_params.compression_enable)
> return;
> @@ -1018,5 +1024,21 @@ void intel_dsc_enable(struct intel_encoder *encoder,
>
> intel_dp_send_dsc_pps_sdp(encoder, crtc_state);
>
> + /* Configure DSS_CTL registers for DSC */
This comment seems redundant.
> + if (crtc_state->cpu_transcoder == TRANSCODER_EDP) {
> + dss_ctl1_reg = DSS_CTL1;
> + dss_ctl2_reg = DSS_CTL2;
> + } else {
> + dss_ctl1_reg = ICL_PIPE_DSS_CTL1(pipe);
> + dss_ctl2_reg = ICL_PIPE_DSS_CTL2(pipe);
Shouldn't these be cpu_transcoder too? Yeah, it's the same thing
essentially, but I think it's better to use the thing that
actually matches the hardware.
I wonder if it would even make sense to do the trans==EDP check
in the macro as well. Would avoid cluttering the code with
details like this. The macro wouldn't be the prettiest thing
ever, but that more or less holds for all reg macros.
> + }
> + dss_ctl2_val |= LEFT_BRANCH_VDSC_ENABLE;
> + if (crtc_state->dsc_params.dsc_split) {
> + dss_ctl2_val |= RIGHT_BRANCH_VDSC_ENABLE;
> + dss_ctl1_val |= JOINER_ENABLE;
> + }
> + I915_WRITE(dss_ctl1_reg, dss_ctl1_val);
> + I915_WRITE(dss_ctl2_reg, dss_ctl2_val);
> +
> return;
> }
> --
> 2.18.0
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 201505] Resume from suspend does not power up the display
https://bugzilla.kernel.org/show_bug.cgi?id=201505 --- Comment #5 from Jan Ziak (http://atom-symbol.net) (0xe2.0x9a.0...@gmail.com) --- Created attachment 279151 --> https://bugzilla.kernel.org/attachment.cgi?id=279151=edit bisect.log I bisected the issue but encountered some inconsistencies along the way: - The bisected commit ends up with a white display after resume-from-suspend, while I was expecting a blank display. - I started bisecting with v4.18 good and v4.19 bad. The bisected commit has date 25 may 2018, while 4.18 has been released on 12 aug 2018. -- 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
[Bug 108521] RX 580 as eGPU amdgpu: gpu post error!
https://bugs.freedesktop.org/show_bug.cgi?id=108521 --- Comment #15 from Robert Strube --- Created attachment 142201 --> https://bugs.freedesktop.org/attachment.cgi?id=142201=edit sudo cat /proc/iomem when eGPU *not* connected sudo cat /proc/iomem when eGPU *not* connected -- 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/syncobj: Avoid kmalloc(GFP_KERNEL) under spinlock
drivers/gpu/drm/drm_syncobj.c:202:4-14: ERROR: function
drm_syncobj_find_signal_pt_for_point called on line 390 inside lock on line 389
but uses GFP_KERNEL
Find functions that refer to GFP_KERNEL but are called with locks held.
Generated by: scripts/coccinelle/locks/call_kern.cocci
v2:
syncobj->timeline still needs protect.
v3:
use a global signaled fence instead of re-allocation.
v4:
Don't need moving lock.
Don't expose func.
Tested by: syncobj_wait and ./deqp-vk -n dEQP-VK.*semaphore* with
lock debug kernel options enabled.
Signed-off-by: Chunming Zhou
Cc: Maarten Lankhorst
Cc: intel-...@lists.freedesktop.org
Cc: Christian König
Cc: Chris Wilson
CC: Julia Lawall
---
drivers/gpu/drm/drm_syncobj.c | 41 ---
1 file changed, 24 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index b7eaa603f368..fab0a2cf672e 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -80,6 +80,23 @@ struct drm_syncobj_signal_pt {
struct list_head list;
};
+static DEFINE_SPINLOCK(signaled_fence_lock);
+static struct dma_fence signaled_fence;
+
+static struct dma_fence *drm_syncobj_signaled_fence_get(void)
+{
+ spin_lock(_fence_lock);
+ if (!signaled_fence.ops) {
+ dma_fence_init(_fence,
+ _syncobj_stub_fence_ops,
+ _fence_lock,
+ 0, 0);
+ dma_fence_signal_locked(_fence);
+ }
+ spin_unlock(_fence_lock);
+
+ return dma_fence_get(_fence);
+}
/**
* drm_syncobj_find - lookup and reference a sync object.
* @file_private: drm file private pointer
@@ -111,24 +128,12 @@ static struct dma_fence
uint64_t point)
{
struct drm_syncobj_signal_pt *signal_pt;
+ struct dma_fence *f = NULL;
if ((syncobj->type == DRM_SYNCOBJ_TYPE_TIMELINE) &&
(point <= syncobj->timeline)) {
- struct drm_syncobj_stub_fence *fence =
- kzalloc(sizeof(struct drm_syncobj_stub_fence),
- GFP_KERNEL);
-
- if (!fence)
- return NULL;
- spin_lock_init(>lock);
- dma_fence_init(>base,
- _syncobj_stub_fence_ops,
- >lock,
- syncobj->timeline_context,
- point);
-
- dma_fence_signal(>base);
- return >base;
+ f = drm_syncobj_signaled_fence_get();
+ goto out;
}
list_for_each_entry(signal_pt, >signal_pt_list, list) {
@@ -137,9 +142,11 @@ static struct dma_fence
if ((syncobj->type == DRM_SYNCOBJ_TYPE_BINARY) &&
(point != signal_pt->value))
continue;
- return dma_fence_get(_pt->fence_array->base);
+ f = dma_fence_get(_pt->fence_array->base);
+ goto out;
}
- return NULL;
+out:
+ return f;
}
static void drm_syncobj_add_callback_locked(struct drm_syncobj *syncobj,
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108542] hdmi issues with kernel 4.18
https://bugs.freedesktop.org/show_bug.cgi?id=108542 --- Comment #1 from Nicholas Kazlauskas --- Thanks for the bisection. Would you mind posting a full dmesg log for your 4.18.8 kernel? -- 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 v6 26/28] drm/i915/dsc: Enable and disable appropriate power wells for VDSC
On Wed, Oct 24, 2018 at 03:28:38PM -0700, Manasi Navare wrote:
> A separate power well 2 (PG2) is required for VDSC on eDP transcoder
> whereas all other transcoders use the power wells associated with the
> transcoders for VDSC.
> This patch adds a helper to obtain correct power domain depending on
> transcoder being used and enables/disables the power wells during
> VDSC enabling/disabling.
>
> v2:
> * Fix tabs, const crtc_state, fix comments (Ville)
>
> Suggested-by: Ville Syrjala
> Cc: Ville Syrjala
> Cc: Imre Deak
> Cc: Rodrigo Vivi
> Signed-off-by: Manasi Navare
> Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_vdsc.c | 26 ++
> 1 file changed, 26 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_vdsc.c
> b/drivers/gpu/drm/i915/intel_vdsc.c
> index 5e76b4a44d90..0fed36e2491a 100644
> --- a/drivers/gpu/drm/i915/intel_vdsc.c
> +++ b/drivers/gpu/drm/i915/intel_vdsc.c
> @@ -581,6 +581,24 @@ int intel_dp_compute_dsc_params(struct intel_dp
> *intel_dp,
> return 0;
> }
>
> +static enum intel_display_power_domain
> +intel_dsc_get_power_domains(const struct intel_crtc_state *crtc_state)
intel_dsc_power_domain() or something like that to match
the naming convention introduced by intel_ddi_main_link_aux_domain()?
Oh, and we'll need to update intel_ddi_get_power_domains() as well.
> +{
> + enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
> +
> + /*
> + * On ICL VDSC/joining for eDP transcoder uses a separate power well PW2
> + * This requires POWER_DOMAIN_TRANSCODER_EDP_VDSC power domain.
> + * For any other transcoder, VDSC/joining uses the power well associated
> + * with the pipe/transcoder in use. Hence another reference on the
> + * transcoder power domain will suffice.
> + */
> + if (cpu_transcoder == TRANSCODER_EDP)
> + return POWER_DOMAIN_TRANSCODER_EDP_VDSC;
> + else
> + return POWER_DOMAIN_TRANSCODER(cpu_transcoder);
> +}
> +
> static void intel_configure_pps_for_dsc_encoder(struct intel_encoder
> *encoder,
> struct intel_crtc_state
> *crtc_state)
> {
> @@ -1020,6 +1038,10 @@ void intel_dsc_enable(struct intel_encoder *encoder,
> if (!crtc_state->dsc_params.compression_enable)
> return;
>
> + /* Enable Power wells for VDSC/joining */
> + intel_display_power_get(dev_priv,
> + intel_dsc_get_power_domains(crtc_state));
> +
> intel_configure_pps_for_dsc_encoder(encoder, crtc_state);
>
> intel_dp_send_dsc_pps_sdp(encoder, crtc_state);
> @@ -1074,4 +1096,8 @@ void intel_dsc_disable(struct intel_encoder *encoder,
> RIGHT_BRANCH_VDSC_ENABLE);
> I915_WRITE(dss_ctl2_reg, dss_ctl2_val);
>
> + /* Disable Power wells for VDSC/joining */
> + intel_display_power_put(dev_priv,
> + intel_dsc_get_power_domains(old_crtc_state));
> +
Bogus newline here.
> }
> --
> 2.18.0
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 3/4] ARM: imx_v6_v7_defconfig: Select TOUCHSCREEN_GOODIX
On Thu, Oct 25, 2018 at 12:11 PM Alex Gonzalez wrote: > > Select CONFIG_TOUCHSCREEN_GOODIX so that we can have functional touch > screen by default on Digi International's AUO/Goodix LCD accessory kit used > with the ConnectCore 6UL SBC Pro (ccimx6ulsbcpro) board. > > Signed-off-by: Alex Gonzalez Reviewed-by: Fabio Estevam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC v1 1/1] imx-drm: match ipu_di_signal_cfg's clk_pol with its observed behaviour.
On Thu, Oct 25, 2018 at 12:17:11PM -0400, thesve...@gmail.com wrote: > From: Sven Van Asbroeck > > We used an oscilloscope to observe the actual polarity of the > DI's pixel clock, and saw the following: > > DI_GENERAL bit 17 is SET: > pixel data is stable on the pixel clock's FALLING edge > DI_GENERAL bit 17 is CLEAR: > pixel data is stable on the pixel clock's RISING edge > > However, the current driver configures the exact opposite of the > behaviour documented in video/imx-ipu-v3.h: > unsigned clk_pol:1; /* true = rising edge */ The definition in the manual is: 17 DI0 Output Clock's polarity di0_polarity_ This bits define the polarity of the DI0's clock. disp_clk1The output clock is active high 0The output clock is active low but what does that mean... There's the hint in IMX6SDLCEC that when the clock is active high, it's expected that the panel will latch data on the _falling_ edge: IPP_DISP_CLK latches data into the panel on its negative edge (when positive polarity is selected). In active mode, IPP_DISP_CLK runs continuously. That seems to imply that when DI_GEN_POLARITY_DISP_CLK is set, it is expected that the panel latches data on the _falling_ edge, not on the positive edge. What this actually means as far as the output signal is not defined very well beyond what I've quoted above in any of the IMX6 manuals that I've checked so far. Now, the interpretation of the comment "/* true = rising edge */" is ambiguous, because it doesn't state what "rising edge" refers to - is that referring to the edge that the data changes, or the edge that the panel is supposed to latch the data. Given what's in the documentation, I'd opt for it describing the edge that the output data changes, not the latch edge. With that interpretation, the existing code is correct. In any case, I suspect if we were to change this as per your patch, we'd end up breaking stuff that works today, thereby causing regressions. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up According to speedtest.net: 11.9Mbps down 500kbps up ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC v2 00/14] kunit: introduce KUnit, the Linux kernel unit testing framework
On 10/23/2018 05:57 PM, Brendan Higgins wrote: > This patch set proposes KUnit, a lightweight unit testing and mocking > framework for the Linux kernel. > > Unlike Autotest and kselftest, KUnit is a true unit testing framework; > it does not require installing the kernel on a test machine or in a VM > and does not require tests to be written in userspace running on a host > kernel. Additionally, KUnit is fast: From invocation to completion KUnit > can run several dozen tests in under a second. Currently, the entire > KUnit test suite for KUnit runs in under a second from the initial > invocation (build time excluded). > > KUnit is heavily inspired by JUnit, Python's unittest.mock, and > Googletest/Googlemock for C++. KUnit provides facilities for defining > unit test cases, grouping related test cases into test suites, providing > common infrastructure for running tests, mocking, spying, and much more. > > ## What's so special about unit testing? > > A unit test is supposed to test a single unit of code in isolation, > hence the name. There should be no dependencies outside the control of > the test; this means no external dependencies, which makes tests orders > of magnitudes faster. Likewise, since there are no external dependencies, > there are no hoops to jump through to run the tests. Additionally, this > makes unit tests deterministic: a failing unit test always indicates a > problem. Finally, because unit tests necessarily have finer granularity, > they are able to test all code paths easily solving the classic problem > of difficulty in exercising error handling code. > > ## Is KUnit trying to replace other testing frameworks for the kernel? > > No. Most existing tests for the Linux kernel are end-to-end tests, which > have their place. A well tested system has lots of unit tests, a > reasonable number of integration tests, and some end-to-end tests. KUnit > is just trying to address the unit test space which is currently not > being addressed. > > ## More information on KUnit > > There is a bunch of documentation near the end of this patch set that > describes how to use KUnit and best practices for writing unit tests. > For convenience I am hosting the compiled docs here: > https://google.github.io/kunit-docs/third_party/kernel/docs/ > > ## Changes Since Last Version > > - Updated patchset to apply cleanly on 4.19. > - Stripped down patchset to focus on just the core features (I dropped >mocking, spying, and the MMIO stuff for now; you can find these >patches here: https://kunit-review.googlesource.com/c/linux/+/1132), >as suggested by Rob. > - Cleaned up some of the commit messages and tweaked commit order a >bit based on suggestions. > I am a bit behind on reviewing this patch series. Just a quick note that I will start looking at these early next week. thanks, -- Shuah ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] drm: tinydrm driver for adafruit PiTFT 3.5" touchscreen
Eric Anholt writes: > I was going to start working on making the vc4 driver work with > tinydrm panels, but it turned out tinydrm didn't have the panel I had > previously bought. So, last night I ported the fbtft staging > driver over to DRM. > > It seems to work (with DT at > https://github.com/anholt/linux/commits/drm-misc-next-hx8357d) -- > fbdev works great including rotated, and so does modetest. However, > when X11 comes up at 16bpp, I get: > > https://photos.app.goo.gl/8tuhzPFFoDGamEfk8 > > If I have tinydrm set a preferred bpp of 24, X looks great. Noralf, > any ideas? Also, with these patches and the format modifier patch I just sent, mesa with vc4 is now working with this driver on this branch: https://gitlab.freedesktop.org/anholt/mesa/commits/kmsro Now I wonder how we can improve performance of the SPI updates. signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [igt-dev] [PATCH] RFC: Make igts for cross-driver stuff mandatory?
Sean Paul writes: > On Fri, Oct 19, 2018 at 10:50:49AM +0200, Daniel Vetter wrote: >> Hi all, >> >> This is just to collect feedback on this idea, and see whether the >> overall dri-devel community stands on all this. I think the past few >> cross-vendor uapi extensions all came with igts attached, and >> personally I think there's lots of value in having them: A >> cross-vendor interface isn't useful if every driver implements it >> slightly differently. >> >> I think there's 2 questions here: >> >> - Do we want to make such testcases mandatory? >> > > Yes, more testing == better code. > > >> - If yes, are we there yet, or is there something crucially missing >> still? > > In my experience, no. Last week while trying to replicate an intel-gfx CI > failure, I tried compiling igt for one of my (intel) chromebooks. It seems > like > cross-compilation (or, in my case, just specifying > prefix/ld_library_path/sbin_path) is broken on igt. If we want to impose > restrictions across the entire subsystem, we need to make sure that everyone > can > build and deploy igt easily. > > I managed to hack around everything and get it working, but I still haven't > tried switching out the toolchain. Once we have some GitLab CI to validate > cross-compilation, then we can consider making IGT mandatory. > > It's possible that I'm just a meson n00b and didn't use the right incantation, > so maybe it already works, but then we need better documentation. > > I've pasted my horrible hacks below, I also didn't have libunwind, so removed > its usage. I've also had to cut out libunwind for cross-compiling on many occasions. Worst library. signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm 1/2] xf86drm: fallback to DRIVER uevent entry when OF_FULLNAME fails
Am Do., 25. Okt. 2018 um 15:35 Uhr schrieb Emil Velikov : > > On Thu, 18 Oct 2018 at 21:07, Christian Gmeiner > wrote: > > > > Signed-off-by: Christian Gmeiner > > --- > > xf86drm.c | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/xf86drm.c b/xf86drm.c > > index 10df682b..4ee1337b 100644 > > --- a/xf86drm.c > > +++ b/xf86drm.c > > @@ -3516,6 +3516,8 @@ static int drmParsePlatformBusInfo(int maj, int min, > > drmPlatformBusInfoPtr info) > > snprintf(path, sizeof(path), "/sys/dev/char/%d:%d/device", maj, min); > > > > name = sysfs_uevent_get(path, "OF_FULLNAME"); > > +if (!name) > > +name = sysfs_uevent_get(path, "DRIVER"); > > This workaround will work for etnaviv, but not for all platform devices. > Personally, I'd recommend reverting the Mesa patch for now... I'm > checking with some kernel-savvy people how we can resolve thing > properly. I am fine with that - will prepare a revert patch. -- greets -- Christian Gmeiner, MSc https://christian-gmeiner.info ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108554] In kernel 4.14.59, monitor resolution is detected correctly. In kernels after that, they are not detected correctly.
https://bugs.freedesktop.org/show_bug.cgi?id=108554 Alex Deucher changed: What|Removed |Added CC||harry.wentl...@amd.com --- Comment #1 from Alex Deucher --- Please attach your xorg log and dmesg output. Can you bisect? -- 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/syncobj: Avoid kmalloc(GFP_KERNEL) under spinlock
Quoting Chunming Zhou (2018-10-25 16:08:31) > drivers/gpu/drm/drm_syncobj.c:202:4-14: ERROR: function > drm_syncobj_find_signal_pt_for_point called on line 390 inside lock on line > 389 but uses GFP_KERNEL > > Find functions that refer to GFP_KERNEL but are called with locks held. > > Generated by: scripts/coccinelle/locks/call_kern.cocci > > v2: > syncobj->timeline still needs protect. > > v3: > use a global signaled fence instead of re-allocation. > > v4: > Don't need moving lock. > Don't expose func. > > Tested by: syncobj_wait and ./deqp-vk -n dEQP-VK.*semaphore* with > lock debug kernel options enabled. > > Signed-off-by: Chunming Zhou > Cc: Maarten Lankhorst > Cc: intel-...@lists.freedesktop.org > Cc: Christian König > Cc: Chris Wilson > CC: Julia Lawall > --- > - return NULL; > +out: > + return f; As it reduced to just a return, I'd probably have gone with multiple returns in this instance. Still the compiler should have done the equivalent and jumped to a single ret. Reviewed-by: Chris Wilson -Chris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 4/4] ARM: dts: ccimx6ulsbcpro: Add support for Goodix touch controller
On Thu, Oct 25, 2018 at 12:10 PM Alex Gonzalez wrote: > > The ConnectCore 6UL SBC Pro has an AUO/Goodix LCD accessory kit that is > connected on the LVDS interface through an on-board LVDS transceiver. > > This change adds support for the touch interface. > > Signed-off-by: Alex Gonzalez Reviewed-by: Fabio Estevam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 2/4] ARM: dts: ccimx6ulsbcpro: Enable AUO G101EVN010 lcdif panel
On Thu, Oct 25, 2018 at 12:11 PM Alex Gonzalez wrote:
>
> This change adds support for the AUO G101EVN010 lcdif panel for the
> mxsfb DRM driver.
>
> Signed-off-by: Alex Gonzalez
> ---
> arch/arm/boot/dts/imx6ul-ccimx6ulsbcpro.dts | 18 ++
> 1 file changed, 18 insertions(+)
>
> diff --git a/arch/arm/boot/dts/imx6ul-ccimx6ulsbcpro.dts
> b/arch/arm/boot/dts/imx6ul-ccimx6ulsbcpro.dts
> index 11966d12af76..f6e6b2cf780b 100644
> --- a/arch/arm/boot/dts/imx6ul-ccimx6ulsbcpro.dts
> +++ b/arch/arm/boot/dts/imx6ul-ccimx6ulsbcpro.dts
> @@ -24,6 +24,18 @@
> status = "okay";
> };
>
> + panel {
> + compatible = "auo,g101evn010", "simple-panel";
The "simple-panel" string could be dropped.
Reviewed-by: Fabio Estevam
> + power-supply = <_ext>;
> + backlight = <_backlight>;
> +
> + port {
> + panel_in: endpoint {
> + remote-endpoint = <_out>;
> + };
> + };
> + };
> +
> reg_usb_otg1_vbus: regulator-usb-otg1 {
> compatible = "regulator-fixed";
> regulator-name = "usb_otg1_vbus";
> @@ -112,6 +124,12 @@
> _lcdif_hvsync>;
> lcd-supply = <_ext>; /* BU90T82 LVDS bridge power */
> status = "okay";
> +
> + port {
> + display_out: endpoint {
> + remote-endpoint = <_in>;
> + };
> + };
> };
>
> _ext {
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/tinydrm: Advertise that we can do only DRM_FORMAT_MOD_LINEAR.
Without this, the xserver relies on what the 3D driver exposes and
assumes that the display can handle it, and then the DRM driver
happily tries to scan out a tiled format.
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/drm_simple_kms_helper.c | 8
drivers/gpu/drm/tinydrm/core/tinydrm-core.c | 1 +
drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c | 6 +-
3 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_simple_kms_helper.c
b/drivers/gpu/drm/drm_simple_kms_helper.c
index 51fa978f0d23..917812448d1b 100644
--- a/drivers/gpu/drm/drm_simple_kms_helper.c
+++ b/drivers/gpu/drm/drm_simple_kms_helper.c
@@ -190,6 +190,13 @@ static void drm_simple_kms_plane_cleanup_fb(struct
drm_plane *plane,
pipe->funcs->cleanup_fb(pipe, state);
}
+static bool drm_simple_kms_format_mod_supported(struct drm_plane *plane,
+ uint32_t format,
+ uint64_t modifier)
+{
+ return modifier == DRM_FORMAT_MOD_LINEAR;
+}
+
static const struct drm_plane_helper_funcs drm_simple_kms_plane_helper_funcs =
{
.prepare_fb = drm_simple_kms_plane_prepare_fb,
.cleanup_fb = drm_simple_kms_plane_cleanup_fb,
@@ -204,6 +211,7 @@ static const struct drm_plane_funcs
drm_simple_kms_plane_funcs = {
.reset = drm_atomic_helper_plane_reset,
.atomic_duplicate_state = drm_atomic_helper_plane_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_plane_destroy_state,
+ .format_mod_supported = drm_simple_kms_format_mod_supported,
};
/**
diff --git a/drivers/gpu/drm/tinydrm/core/tinydrm-core.c
b/drivers/gpu/drm/tinydrm/core/tinydrm-core.c
index 255341ee4eb9..9af51d982a33 100644
--- a/drivers/gpu/drm/tinydrm/core/tinydrm-core.c
+++ b/drivers/gpu/drm/tinydrm/core/tinydrm-core.c
@@ -146,6 +146,7 @@ static int tinydrm_init(struct device *parent, struct
tinydrm_device *tdev,
drm->dev_private = tdev;
drm_mode_config_init(drm);
drm->mode_config.funcs = _mode_config_funcs;
+ drm->mode_config.allow_fb_modifiers = true;
return 0;
}
diff --git a/drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c
b/drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c
index 7e8e24d0b7a7..eacfc0ec8ff1 100644
--- a/drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c
+++ b/drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c
@@ -184,6 +184,10 @@ tinydrm_display_pipe_init(struct tinydrm_device *tdev,
struct drm_display_mode mode_copy;
struct drm_connector *connector;
int ret;
+ static const uint64_t modifiers[] = {
+ DRM_FORMAT_MOD_LINEAR,
+ DRM_FORMAT_MOD_INVALID
+ };
drm_mode_copy(_copy, mode);
ret = tinydrm_rotate_mode(_copy, rotation);
@@ -202,6 +206,6 @@ tinydrm_display_pipe_init(struct tinydrm_device *tdev,
return PTR_ERR(connector);
return drm_simple_display_pipe_init(drm, >pipe, funcs, formats,
- format_count, NULL, connector);
+ format_count, modifiers, connector);
}
EXPORT_SYMBOL(tinydrm_display_pipe_init);
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: fix call_kern.cocci warnings v3
Op 25-10-18 om 14:01 schreef Chunming Zhou:
>
> 在 2018/10/25 18:36, Maarten Lankhorst 写道:
>> Op 25-10-18 om 12:21 schreef Chunming Zhou:
>>> drivers/gpu/drm/drm_syncobj.c:202:4-14: ERROR: function
>>> drm_syncobj_find_signal_pt_for_point called on line 390 inside lock on line
>>> 389 but uses GFP_KERNEL
>>>
>>>Find functions that refer to GFP_KERNEL but are called with locks held.
>>>
>>> Generated by: scripts/coccinelle/locks/call_kern.cocci
>>>
>>> v2:
>>> syncobj->timeline still needs protect.
>>>
>>> v3:
>>> use a global signaled fence instead of re-allocation.
>>>
>>> Signed-off-by: Chunming Zhou
>>> Cc: Maarten Lankhorst
>>> Cc: intel-...@lists.freedesktop.org
>>> Cc: Christian König
>>> ---
>>> drivers/gpu/drm/drm_drv.c | 2 ++
>>> drivers/gpu/drm/drm_syncobj.c | 52 +--
>>> include/drm/drm_syncobj.h | 1 +
>>> 3 files changed, 34 insertions(+), 21 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
>>> index 36e8e9cbec52..0a6f1023d6c3 100644
>>> --- a/drivers/gpu/drm/drm_drv.c
>>> +++ b/drivers/gpu/drm/drm_drv.c
>>> @@ -37,6 +37,7 @@
>>> #include
>>> #include
>>> #include
>>> +#include
>>>
>>> #include "drm_crtc_internal.h"
>>> #include "drm_legacy.h"
>>> @@ -1003,6 +1004,7 @@ static int __init drm_core_init(void)
>>> if (ret < 0)
>>> goto error;
>>>
>>> + drm_syncobj_stub_fence_init();
>>> drm_core_init_complete = true;
>>>
>>> DRM_DEBUG("Initialized\n");
>>> diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
>>> index b7eaa603f368..6b3f5a06e4d3 100644
>>> --- a/drivers/gpu/drm/drm_syncobj.c
>>> +++ b/drivers/gpu/drm/drm_syncobj.c
>>> @@ -80,6 +80,27 @@ struct drm_syncobj_signal_pt {
>>> struct list_head list;
>>> };
>>>
>>> +static struct drm_syncobj_stub_fence stub_signaled_fence;
>>> +static void global_stub_fence_release(struct dma_fence *fence)
>>> +{
>>> + /* it is impossible to come here */
>>> + BUG();
>>> +}
>> WARN_ON_ONCE(1)? No need to halt the machine.
>>
>>> +static const struct dma_fence_ops global_stub_fence_ops = {
>>> + .get_driver_name = drm_syncobj_stub_fence_get_name,
>>> + .get_timeline_name = drm_syncobj_stub_fence_get_name,
>>> + .release = global_stub_fence_release,
>>> +};
>>> +
>>> +void drm_syncobj_stub_fence_init(void)
>>> +{
>>> + spin_lock_init(_signaled_fence.lock);
>>> + dma_fence_init(_signaled_fence.base,
>>> + _stub_fence_ops,
>>> + _signaled_fence.lock,
>>> + 0, 0);
>>> + dma_fence_signal(_signaled_fence.base);
>>> +}
>>> /**
>>>* drm_syncobj_find - lookup and reference a sync object.
>>>* @file_private: drm file private pointer
>>> @@ -111,24 +132,14 @@ static struct dma_fence
>>> uint64_t point)
>>> {
>>> struct drm_syncobj_signal_pt *signal_pt;
>>> + struct dma_fence *f = NULL;
>>>
>>> + spin_lock(>pt_lock);
>>> if ((syncobj->type == DRM_SYNCOBJ_TYPE_TIMELINE) &&
>>> (point <= syncobj->timeline)) {
>>> - struct drm_syncobj_stub_fence *fence =
>>> - kzalloc(sizeof(struct drm_syncobj_stub_fence),
>>> - GFP_KERNEL);
>>> -
>>> - if (!fence)
>>> - return NULL;
>>> - spin_lock_init(>lock);
>>> - dma_fence_init(>base,
>>> - _syncobj_stub_fence_ops,
>>> - >lock,
>>> - syncobj->timeline_context,
>>> - point);
>>> -
>>> - dma_fence_signal(>base);
>>> - return >base;
>>> + dma_fence_get(_signaled_fence.base);
>>> + spin_unlock(>pt_lock);
>>> + return _signaled_fence.base;
>>> }
>>>
>>> list_for_each_entry(signal_pt, >signal_pt_list, list) {
>>> @@ -137,9 +148,12 @@ static struct dma_fence
>>> if ((syncobj->type == DRM_SYNCOBJ_TYPE_BINARY) &&
>>> (point != signal_pt->value))
>>> continue;
>>> - return dma_fence_get(_pt->fence_array->base);
>>> + f = dma_fence_get(_pt->fence_array->base);
>>> + break;
>>> }
>>> - return NULL;
>>> + spin_unlock(>pt_lock);
>>> +
>>> + return f;
>>> }
>>>
>>> static void drm_syncobj_add_callback_locked(struct drm_syncobj *syncobj,
>>> @@ -166,9 +180,7 @@ static void
>>> drm_syncobj_fence_get_or_add_callback(struct drm_syncobj *syncobj,
>>> }
>>>
>>> mutex_lock(>cb_mutex);
>>> - spin_lock(>pt_lock);
>>> *fence = drm_syncobj_find_signal_pt_for_point(syncobj, pt_value);
>>> - spin_unlock(>pt_lock);
>>> if (!*fence)
>>> drm_syncobj_add_callback_locked(syncobj, cb, func);
>>> mutex_unlock(>cb_mutex);
>>> @@ -379,11 +391,9 @@ drm_syncobj_point_get(struct drm_syncobj *syncobj, u64
>>> point, u64 flags,
>>> if (ret < 0)
>>>
[Bug 108554] In kernel 4.14.59, monitor resolution is detected correctly. In kernels after that, they are not detected correctly.
https://bugs.freedesktop.org/show_bug.cgi?id=108554 Bug ID: 108554 Summary: In kernel 4.14.59, monitor resolution is detected correctly. In kernels after that, they are not detected correctly. Product: DRI Version: XOrg git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: carav...@gmail.com Hello, Open bug in launchpad.net https://bugs.launchpad.net/bugs/1799613 "Booting from GRUB into 4.14.59 allows my two monitors to run at their native resolution, 2560x1440. Any newer kernel does not allow my two monitors to run at their native resolution, only allowing up to 1920x1200." Best regards, -- Cristian Aravena Romero (caravena) -- 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/3] A DRM API for adaptive sync and variable refresh rate support
On 2018-10-12 4:31 a.m., Koenig, Christian wrote: > Am 12.10.2018 um 10:26 schrieb Michel Dänzer: >> On 2018-10-11 9:44 p.m., Harry Wentland wrote: >>> On 2018-10-03 04:25 AM, Mike Lothian wrote: I'm curious to know whether this will/could work over PRIME >>> I don't see why this shouldn't work over PRIME as long as the >>> presenting GPU supports the new variable refresh rate API, but I know >>> very little about prime, so maybe someone else can chime in and give >>> a better opinion. >> It won't work for displays connected to a secondary GPU, because those >> aren't hooked up to the Present extension directly. >> >> It can theoretically work with render offloading, if the primary GPU can >> scan out directly from the shared pixmap. This is only possible with >> current AMD APUs which support scatter/gather scanout (Carrizo and >> newer?). > > Actually only Carizzo and Stoney at the moment because this is buggy on > Raven. Not sure if that is a pure software or a hardware problem. > > Christian. > >> One gotcha is that xf86-video-amdgpu currently doesn't allow >> flipping between buffers with different tiling parameters (BTW Harry, >> does that work with DC?), but that should be easy to fix. > Not currently. Fixable, but unfortunately not as easy as I'd hope. The good news is that I'm planning to rework that code so it would be easy to fix or should just happen on a per-flip basis. Harry ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 1/4] drm: Add vrr_capable property to the drm connector
On 2018-10-12 12:44 p.m., Nicholas Kazlauskas wrote:
> Modern display hardware is capable of supporting variable refresh rates.
> This patch introduces the "vrr_capable" property on the connector to
> allow userspace to query support for variable refresh rates.
>
> Atomic drivers should attach this property to connectors that are
> capable of driving variable refresh rates using
> drm_connector_attach_vrr_capable_property().
>
> The value should be updated based on driver and hardware capabiltiy
> by using drm_connector_set_vrr_capable_property().
>
> Signed-off-by: Nicholas Kazlauskas
Reviewed-by: Harry Wentland
Harry
> ---
> drivers/gpu/drm/drm_connector.c | 49 +
> include/drm/drm_connector.h | 15 ++
> 2 files changed, 64 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 1e40e5decbe9..f0deeb7298d0 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -1254,6 +1254,37 @@ int drm_mode_create_scaling_mode_property(struct
> drm_device *dev)
> }
> EXPORT_SYMBOL(drm_mode_create_scaling_mode_property);
>
> +/**
> + * drm_connector_attach_vrr_capable_property - creates the
> + * vrr_capable property
> + * @connector: connector to create the vrr_capable property on.
> + *
> + * This is used by atomic drivers to add support for querying
> + * variable refresh rate capability for a connector.
> + *
> + * Returns:
> + * Zero on success, negative errono on failure.
> + */
> +int drm_connector_attach_vrr_capable_property(
> + struct drm_connector *connector)
> +{
> + struct drm_device *dev = connector->dev;
> + struct drm_property *prop;
> +
> + if (!connector->vrr_capable_property) {
> + prop = drm_property_create_bool(dev, DRM_MODE_PROP_IMMUTABLE,
> + "vrr_capable");
> + if (!prop)
> + return -ENOMEM;
> +
> + connector->vrr_capable_property = prop;
> + drm_object_attach_property(>base, prop, 0);
> + }
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_connector_attach_vrr_capable_property);
> +
> /**
> * drm_connector_attach_scaling_mode_property - attach atomic scaling mode
> property
> * @connector: connector to attach scaling mode property on.
> @@ -1582,6 +1613,24 @@ void drm_connector_set_link_status_property(struct
> drm_connector *connector,
> }
> EXPORT_SYMBOL(drm_connector_set_link_status_property);
>
> +/**
> + * drm_connector_set_vrr_capable_property - sets the variable refresh rate
> + * capable property for a connector
> + * @connector: drm connector
> + * @capable: True if the connector is variable refresh rate capable
> + *
> + * Should be used by atomic drivers to update the indicated support for
> + * variable refresh rate over a connector.
> + */
> +void drm_connector_set_vrr_capable_property(
> + struct drm_connector *connector, bool capable)
> +{
> + drm_object_property_set_value(>base,
> + connector->vrr_capable_property,
> + capable);
> +}
> +EXPORT_SYMBOL(drm_connector_set_vrr_capable_property);
> +
> /**
> * drm_connector_init_panel_orientation_property -
> * initialize the connecters panel_orientation property
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index 91a877fa00cb..b2263005234a 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -910,6 +910,17 @@ struct drm_connector {
>*/
> struct drm_property *scaling_mode_property;
>
> + /**
> + * @vrr_capable_property: Optional property to help userspace
> + * query hardware support for variable refresh rate on a connector.
> + * connector. Drivers can add the property to a connector by
> + * calling drm_connector_attach_vrr_capable_property().
> + *
> + * This should be updated only by calling
> + * drm_connector_set_vrr_capable_property().
> + */
> + struct drm_property *vrr_capable_property;
> +
> /**
>* @content_protection_property: DRM ENUM property for content
>* protection. See drm_connector_attach_content_protection_property().
> @@ -1183,6 +1194,8 @@ int drm_mode_create_scaling_mode_property(struct
> drm_device *dev);
> int drm_connector_attach_content_type_property(struct drm_connector *dev);
> int drm_connector_attach_scaling_mode_property(struct drm_connector
> *connector,
> u32 scaling_mode_mask);
> +int drm_connector_attach_vrr_capable_property(
> + struct drm_connector *connector);
> int drm_connector_attach_content_protection_property(
> struct drm_connector *connector);
> int drm_mode_create_aspect_ratio_property(struct drm_device *dev);
> @@ -1199,6 +1212,8 @@ int drm_connector_update_edid_property(struct
> drm_connector *connector,
>
Re: [PATCH v10 1/2] drm/panel: Add support for Truly NT35597 panel driver
On Fri, Oct 05, 2018 at 05:52:18PM -0700, Abhinav Kumar wrote:
> Add support for Truly NT35597 panel driver used in MSM reference
> platforms. This panel driver supports both single DSI and dual
> DSI modes.
>
> However, this patch series adds support only for dual DSI mode.
>
> Changes in v10:
> - None
>
> Reviewed-by: Sean Paul
> Signed-off-by: Archit Taneja
> Signed-off-by: Abhinav Kumar
Thanks for keeping up with these patches, I've applied both to drm-misc-next.
Sean
> ---
> drivers/gpu/drm/panel/Kconfig | 7 +
> drivers/gpu/drm/panel/Makefile | 1 +
> drivers/gpu/drm/panel/panel-truly-nt35597.c | 675
>
> 3 files changed, 683 insertions(+)
> create mode 100644 drivers/gpu/drm/panel/panel-truly-nt35597.c
>
> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
> index 6020c30..073ffa0 100644
> --- a/drivers/gpu/drm/panel/Kconfig
> +++ b/drivers/gpu/drm/panel/Kconfig
> @@ -186,4 +186,11 @@ config DRM_PANEL_SITRONIX_ST7789V
> Say Y here if you want to enable support for the Sitronix
> ST7789V controller for 240x320 LCD panels
>
> +config DRM_PANEL_TRULY_NT35597_WQXGA
> + tristate "Truly WQXGA"
> + depends on OF
> + depends on DRM_MIPI_DSI
> + help
> + Say Y here if you want to enable support for Truly NT35597 WQXGA Dual
> DSI
> + Video Mode panel
> endmenu
> diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
> index 5ccaaa9..80fd19f 100644
> --- a/drivers/gpu/drm/panel/Makefile
> +++ b/drivers/gpu/drm/panel/Makefile
> @@ -19,3 +19,4 @@ obj-$(CONFIG_DRM_PANEL_SEIKO_43WVF1G) +=
> panel-seiko-43wvf1g.o
> obj-$(CONFIG_DRM_PANEL_SHARP_LQ101R1SX01) += panel-sharp-lq101r1sx01.o
> obj-$(CONFIG_DRM_PANEL_SHARP_LS043T1LE01) += panel-sharp-ls043t1le01.o
> obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7789V) += panel-sitronix-st7789v.o
> +obj-$(CONFIG_DRM_PANEL_TRULY_NT35597_WQXGA) += panel-truly-nt35597.o
> diff --git a/drivers/gpu/drm/panel/panel-truly-nt35597.c
> b/drivers/gpu/drm/panel/panel-truly-nt35597.c
> new file mode 100644
> index 000..fc2a66c
> --- /dev/null
> +++ b/drivers/gpu/drm/panel/panel-truly-nt35597.c
> @@ -0,0 +1,675 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2018, The Linux Foundation. All rights reserved.
> + */
> +
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +
> +static const char * const regulator_names[] = {
> + "vdda",
> + "vdispp",
> + "vdispn",
> +};
> +
> +static unsigned long const regulator_enable_loads[] = {
> + 62000,
> + 10,
> + 10,
> +};
> +
> +static unsigned long const regulator_disable_loads[] = {
> + 80,
> + 100,
> + 100,
> +};
> +
> +struct cmd_set {
> + u8 commands[4];
> + u8 size;
> +};
> +
> +struct nt35597_config {
> + u32 width_mm;
> + u32 height_mm;
> + const char *panel_name;
> + const struct cmd_set *panel_on_cmds;
> + u32 num_on_cmds;
> + const struct drm_display_mode *dm;
> +};
> +
> +struct truly_nt35597 {
> + struct device *dev;
> + struct drm_panel panel;
> +
> + struct regulator_bulk_data supplies[ARRAY_SIZE(regulator_names)];
> +
> + struct gpio_desc *reset_gpio;
> + struct gpio_desc *mode_gpio;
> +
> + struct backlight_device *backlight;
> +
> + struct mipi_dsi_device *dsi[2];
> +
> + const struct nt35597_config *config;
> + bool prepared;
> + bool enabled;
> +};
> +
> +static inline struct truly_nt35597 *panel_to_ctx(struct drm_panel *panel)
> +{
> + return container_of(panel, struct truly_nt35597, panel);
> +}
> +
> +static const struct cmd_set qcom_2k_panel_magic_cmds[] = {
> + /* CMD2_P0 */
> + { { 0xff, 0x20 }, 2 },
> + { { 0xfb, 0x01 }, 2 },
> + { { 0x00, 0x01 }, 2 },
> + { { 0x01, 0x55 }, 2 },
> + { { 0x02, 0x45 }, 2 },
> + { { 0x05, 0x40 }, 2 },
> + { { 0x06, 0x19 }, 2 },
> + { { 0x07, 0x1e }, 2 },
> + { { 0x0b, 0x73 }, 2 },
> + { { 0x0c, 0x73 }, 2 },
> + { { 0x0e, 0xb0 }, 2 },
> + { { 0x0f, 0xae }, 2 },
> + { { 0x11, 0xb8 }, 2 },
> + { { 0x13, 0x00 }, 2 },
> + { { 0x58, 0x80 }, 2 },
> + { { 0x59, 0x01 }, 2 },
> + { { 0x5a, 0x00 }, 2 },
> + { { 0x5b, 0x01 }, 2 },
> + { { 0x5c, 0x80 }, 2 },
> + { { 0x5d, 0x81 }, 2 },
> + { { 0x5e, 0x00 }, 2 },
> + { { 0x5f, 0x01 }, 2 },
> + { { 0x72, 0x11 }, 2 },
> + { { 0x68, 0x03 }, 2 },
> + /* CMD2_P4 */
> + { { 0xFF, 0x24 }, 2 },
> + { { 0xFB, 0x01 }, 2 },
> + { { 0x00, 0x1C }, 2 },
> + { { 0x01, 0x0B }, 2 },
> + { { 0x02, 0x0C }, 2 },
> + { { 0x03, 0x01 }, 2 },
> + { { 0x04, 0x0F }, 2 },
> + { { 0x05, 0x10 }, 2 },
> + { { 0x06, 0x10 }, 2 },
> + { { 0x07, 0x10 }, 2 },
> + { { 0x08, 0x89 }, 2 },
> + { { 0x09, 0x8A }, 2 },
> + { { 0x0A, 0x13 }, 2 },
> + { { 0x0B, 0x13 }, 2
Re: [PATCH 5/6] drm/panel: simple: Innolux TV123WAM is actually P120ZDG-BF1
Hi,
On Thu, Oct 25, 2018 at 11:13 AM Sean Paul wrote:
>
> On Mon, Oct 22, 2018 at 01:46:38PM -0700, Douglas Anderson wrote:
> > As far as I can tell the panel that was added in commit da50bd4258db
> > ("drm/panel: simple: Add Innolux TV123WAM panel driver support")
> > wasn't actually an Innolux TV123WAM but was actually an Innolux
> > P120ZDG-BF1.
> >
> > As far as I can tell the Innolux TV123WAM isn't a real panel and but
> > it's a mosh between the TI TV123WAM and the Innolux P120ZDG-BF1.
> > Let's unmosh.
> >
> > Here's my evidence:
> >
> > * Searching for TV123WAM on the Internet turns up a TI panel. While
> > it's possible that an Innolux panel has the same model number as the
> > TI Panel, it seems a little doubtful. Looking up the datasheet from
> > the TI Panel shows that it's 1920 x 1280 and 259.2 mm x 172.8 mm.
> >
> > * As far as I know, the patch adding the Innolux Panel was supposed to
> > be for the board that's sitting in front of me as I type this
> > (support for that board is not yet upstream). On the back of that
> > panel I see Innolux P120ZDZ-EZ1 rev B1.
> >
> > * Someone pointed me at a datasheet that's supposed to be for the
> > panel in front of me (sorry, I can't share the datasheet). That
> > datasheet has the string "p120zdg-bf1"
> >
> > * If I search for "P120ZDG-BF1" on the Internet I get hits for panels
> > that are 2160x1440. They don't have datasheets, but the fact that
> > the resolution matches is a good sign.
> >
> > In any case, let's update the name and also the physical size to match
> > the correct panel.
> >
> > Fixes: da50bd4258db ("drm/panel: simple: Add Innolux TV123WAM panel driver
> > support")
> > Signed-off-by: Douglas Anderson
> > Cc: Sandeep Panda
> > ---
> >
> > drivers/gpu/drm/panel/panel-simple.c | 14 +++---
> > 1 file changed, 7 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/panel/panel-simple.c
> > b/drivers/gpu/drm/panel/panel-simple.c
> > index 937e97490c30..7ee1abc5d81b 100644
> > --- a/drivers/gpu/drm/panel/panel-simple.c
> > +++ b/drivers/gpu/drm/panel/panel-simple.c
> > @@ -1370,7 +1370,7 @@ static const struct panel_desc innolux_n156bge_l21 = {
> > },
> > };
> >
> > -static const struct drm_display_mode innolux_tv123wam_mode = {
> > +static const struct drm_display_mode innolux_p120zdg_bf1_mode = {
> > .clock = 206016,
> > .hdisplay = 2160,
> > .hsync_start = 2160 + 48,
> > @@ -1384,13 +1384,13 @@ static const struct drm_display_mode
> > innolux_tv123wam_mode = {
> > .flags = DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC,
> > };
> >
> > -static const struct panel_desc innolux_tv123wam = {
> > - .modes = _tv123wam_mode,
> > +static const struct panel_desc innolux_p120zdg_bf1 = {
> > + .modes = _p120zdg_bf1_mode,
> > .num_modes = 1,
> > .bpc = 8,
> > .size = {
> > - .width = 259,
> > - .height = 173,
> > + .width = 254,
> > + .height = 169,
> > },
> > .delay = {
> > .prepare = 200,
> > @@ -2454,8 +2454,8 @@ static const struct of_device_id platform_of_match[]
> > = {
> > .compatible = "innolux,n156bge-l21",
> > .data = _n156bge_l21,
> > }, {
> > - .compatible = "innolux,tv123wam",
>
> I think we should update the struct, but we might want to keep this around.
> Given the tv123wam panel is TI, we're likely not going to have a collision on
> innolux,...
>
> That said, I'll defer to robh on this one, I'm not sure if changing names is
> cool once the bindings have hit mainline.
Rob gave the bindings patch a Reviewed-by tag, so I'm assuming he's
cool with it. v2 still doesn't keep the "innolux,tv123wam" around.
If you disagree then let me know and I'll do a v3.
-Doug
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] dt-bindings: new binding for Himax HX8357D display panels
On Wed, Oct 24, 2018 at 11:43:11AM -0700, Eric Anholt wrote:
> This adds a new binding for Himax HX8357D display panels. It includes
> a compatible string for one display (more can be added in the future).
>
> The YX350HV15 panel[1] is found in the Adafruit PiTFT 3.5" Touch
> Screen for Raspberry Pi.
>
> [1]
> https://learn.adafruit.com/adafruit-pitft-3-dot-5-touch-screen-for-raspberry-pi/downloads
>
> This binding is closely modeled after the ili9341 binding, for a
> similar product from adafruit. The primary difference is that the
> hx8367d doesn't have a reset line that I can find in the schematics.
>
> Signed-off-by: Eric Anholt
> ---
> .../bindings/display/himax,hx8357d.txt| 25 +++
> 1 file changed, 25 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/himax,hx8357d.txt
>
> diff --git a/Documentation/devicetree/bindings/display/himax,hx8357d.txt
> b/Documentation/devicetree/bindings/display/himax,hx8357d.txt
> new file mode 100644
> index ..48586e570be0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/himax,hx8357d.txt
> @@ -0,0 +1,25 @@
> +Himax HX8357D display panels
> +
> +This binding is for display panels using a Himax HX8357D controller in SPI
> +mode, such as the Adafruit 3.5" TFT for Raspberry Pi.
> +
> +Required properties:
> +- compatible:"adafruit,yx350hv15", "himax,hx8357d"
> +- dc-gpios: D/C pin
You forgot reg. Otherwise,
Reviewed-by: Rob Herring
> +
> +The node for this driver must be a child node of a SPI controller, hence
> +all mandatory properties described in ../spi/spi-bus.txt must be specified.
> +
> +Optional properties:
> +- rotation: panel rotation in degrees counter clockwise (0,90,180,270)
> +- backlight: phandle of the backlight device attached to the panel
> +
> +Example:
> + display@0{
> + compatible = "adafruit,yx350hv15", "himax,hx8357d";
> + reg = <0>;
> + spi-max-frequency = <3200>;
> + dc-gpios = < 25 GPIO_ACTIVE_HIGH>;
> + rotation = <90>;
> + backlight = <>;
> + };
> --
> 2.19.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RESEND PATCH 1/2] drm/panel: Add support for Armadeus ST0700 Adapt
On Wed, 24 Oct 2018 14:54:56 +0200, =?UTF-8?q?S=C3=A9bastien=20Szymanski?= wrote: > This patch adds support for the Armadeus ST0700 Adapt. It comes with a > Santek ST0700I5Y-RBSLW 7.0" WVGA (800x480) TFT and an adapter board so > that it can be connected on the TFT header of Armadeus Dev boards. > > Signed-off-by: Sébastien Szymanski > --- > .../display/panel/armadeus,st0700-adapt.txt| 9 +++ > drivers/gpu/drm/panel/panel-simple.c | 29 > ++ > 2 files changed, 38 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/panel/armadeus,st0700-adapt.txt > Reviewed-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 4/6] drm/bridge: ti-sn65dsi86: Remove the mystery delay
Let's solve the mystery of commit bf1178c98930 ("drm/bridge:
ti-sn65dsi86: Add mystery delay to enable()"). Specifically the
reason we needed that mystery delay is that we weren't paying
attention to HPD.
Looking at the datasheet for the same panel that was tested for the
original commit, I see there's a timing "t3" that times from power on
to the aux channel being operational. This time is specced as 0 - 200
ms. The datasheet says that the aux channel is operational at exactly
the same time that HPD is asserted.
Scoping the signals on this board showed that HPD was asserted 84 ms
after power was asserted. That very closely matches the magic 70 ms
delay that we had. ...and actually, in my testing the 70 ms wasn't
quite enough of a delay and some percentage of the time the display
didn't come up until I bumped it to 100 ms (presumably 84 ms would
have worked too).
To solve this, we tried to hook up the HPD signal in the bridge.
...but in doing so we found that that the bridge didn't report that
HPD was asserted until ~280 ms after we powered it (!). This is
explained by looking at the sn65dsi86 datasheet section "8.4.5.1 HPD
(Hot Plug/Unplug Detection)". Reading there we see that the bridge
isn't even intended to report HPD until 100 ms after it's asserted.
...but that would have left us at 184 ms. The extra 100 ms
(presumably) comes from this part in the datasheet:
> The HPD state machine operates off an internal ring oscillator. The
> ring oscillator frequency will vary [ ... ]. The min/max range in
> the HPD State Diagram refers to the possible times based off
> variation in the ring oscillator frequency.
Given that the 280 ms we'll end up delaying if we hook up HPD is
_slower_ than the 200 ms we could just hardcode, for now we'll solve
the problem by just hardcoding a 200 ms delay in the panel driver
using the patch in this series ("drm/panel: simple: Support panels
with HPD where HPD isn't connected").
If we later find a panel that needs to use this bridge where we need
HPD then we'll have to come up with some new code to handle it. Given
the silly debouncing in the bridge chip, though, it seems unlikely.
One last note is that I tried to solve this through another way: In
ti_sn_bridge_enable() I tried to use various combinations of
dp_dpcd_writeb() and dp_dpcd_readb() to detect when the aux channel
was up. In theory that would let me detect _exactly_ when I could
continue and do link training. Unfortunately even if I did an aux
transfer w/out waiting I couldn't see any errors. Possibly I could
keep looping over link training until it came back with success, but
that seemed a little overly hacky to me.
Signed-off-by: Douglas Anderson
Reviewed-by: Sean Paul
---
Changes in v2: None
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 29 +++
1 file changed, 16 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
index f8a931cf3665..680566d97adc 100644
--- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
+++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
@@ -458,18 +458,6 @@ static void ti_sn_bridge_enable(struct drm_bridge *bridge)
unsigned int val;
int ret;
- /*
-* FIXME:
-* This 70ms was found necessary by experimentation. If it's not
-* present, link training fails. It seems like it can go anywhere from
-* pre_enable() up to semi-auto link training initiation below.
-*
-* Neither the datasheet for the bridge nor the panel tested mention a
-* delay of this magnitude in the timing requirements. So for now, add
-* the mystery delay until someone figures out a better fix.
-*/
- msleep(70);
-
/* DSI_A lane config */
val = CHA_DSI_LANES(4 - pdata->dsi->lanes);
regmap_update_bits(pdata->regmap, SN_DSI_LANES_REG,
@@ -536,7 +524,22 @@ static void ti_sn_bridge_pre_enable(struct drm_bridge
*bridge)
/* configure bridge ref_clk */
ti_sn_bridge_set_refclk_freq(pdata);
- /* in case drm_panel is connected then HPD is not supported */
+ /*
+* HPD on this bridge chip is a bit useless. This is an eDP bridge
+* so the HPD is an internal signal that's only there to signal that
+* the panel is done powering up. ...but the bridge chip debounces
+* this signal by between 100 ms and 400 ms (depending on process,
+* voltage, and temperate--I measured it at about 200 ms). One
+* particular panel asserted HPD 84 ms after it was powered on meaning
+* that we saw HPD 284 ms after power on. ...but the same panel said
+* that instead of looking at HPD you could just hardcode a delay of
+* 200 ms. We'll assume that the panel driver will have the hardcoded
+* delay in its prepare and always disable HPD.
+*
+* If HPD somehow makes sense on some future panel we'll have to
+* change this
[PATCH v2 2/6] drm/panel: simple: Support panels with HPD where HPD isn't connected
Some eDP panels that are designed to be always connected to a board
use their HPD signal to signal that they've finished powering on and
they're ready to be talked to.
However, for various reasons it's possible that the HPD signal from
the panel isn't actually hooked up. In the case where the HPD isn't
hooked up you can look at the timing diagram on the panel datasheet
and insert a delay for the maximum amount of time that the HPD might
take to come up.
Let's add support in simple-panel for this concept.
At the moment we will co-opt the existing "prepare" delay to keep
track of the delay and we'll use a boolean to specify that a given
panel should only apply the delay if the "no-hpd" property was
specified.
Signed-off-by: Douglas Anderson
---
Changes in v2:
- Use "hpd_absent_delay" property instead of a bool + prepare delay
drivers/gpu/drm/panel/panel-simple.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 97964f7f2ace..687fd087b9fc 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -56,6 +56,8 @@ struct panel_desc {
/**
* @prepare: the time (in milliseconds) that it takes for the panel to
* become ready and start receiving video data
+* @hpd_absent_delay: Add this to the prepare delay if we know Hot
+*Plug Detect isn't used.
* @enable: the time (in milliseconds) that it takes for the panel to
* display the first valid frame after starting to receive
* video data
@@ -66,6 +68,7 @@ struct panel_desc {
*/
struct {
unsigned int prepare;
+ unsigned int hpd_absent_delay;
unsigned int enable;
unsigned int disable;
unsigned int unprepare;
@@ -79,6 +82,7 @@ struct panel_simple {
struct drm_panel base;
bool prepared;
bool enabled;
+ bool no_hpd;
const struct panel_desc *desc;
@@ -202,6 +206,7 @@ static int panel_simple_unprepare(struct drm_panel *panel)
static int panel_simple_prepare(struct drm_panel *panel)
{
struct panel_simple *p = to_panel_simple(panel);
+ unsigned int delay;
int err;
if (p->prepared)
@@ -215,8 +220,11 @@ static int panel_simple_prepare(struct drm_panel *panel)
gpiod_set_value_cansleep(p->enable_gpio, 1);
- if (p->desc->delay.prepare)
- msleep(p->desc->delay.prepare);
+ delay = p->desc->delay.prepare;
+ if (p->no_hpd)
+ delay += p->desc->delay.hpd_absent_delay;
+ if (delay)
+ msleep(delay);
p->prepared = true;
@@ -305,6 +313,8 @@ static int panel_simple_probe(struct device *dev, const
struct panel_desc *desc)
panel->prepared = false;
panel->desc = desc;
+ panel->no_hpd = of_property_read_bool(dev->of_node, "no-hpd");
+
panel->supply = devm_regulator_get(dev, "power");
if (IS_ERR(panel->supply))
return PTR_ERR(panel->supply);
--
2.19.1.568.g152ad8e336-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 5/6] dt-bindings: drm/panel: simple: Innolux TV123WAM is actually P120ZDG-BF1
As far as I can tell the bindings that were added in commit
9c04400f7ea6 ("dt-bindings: drm/panel: Document Innolux TV123WAM panel
bindings") weren't actually for Innolux TV123WAM but were actually for
Innolux P120ZDG-BF1.
As far as I can tell the Innolux TV123WAM isn't a real panel and but
it's a mosh between the TI TV123WAM and the Innolux P120ZDG-BF1.
Let's unmosh.
Here's my evidence:
* Searching for TV123WAM on the Internet turns up a TI panel. While
it's possible that an Innolux panel has the same model number as the
TI Panel, it seems a little doubtful. Looking up the datasheet from
the TI Panel shows that it's 1920 x 1280 and 259.2 mm x 172.8 mm.
* As far as I know, the patch adding the Innolux Panel was supposed to
be for the board that's sitting in front of me as I type this
(support for that board is not yet upstream). On the back of that
panel I see Innolux P120ZDZ-EZ1 rev B1.
* Someone pointed me at a datasheet that's supposed to be for the
panel in front of me (sorry, I can't share the datasheet). That
datasheet has the string "p120zdg-bf1"
* If I search for "P120ZDG-BF1" on the Internet I get hits for panels
that are 2160x1440. They don't have datasheets, but the fact that
the resolution matches is a good sign.
While we doing the rename, also mention that no-hpd can be used with
this panel. See the previous patch in this series ("drm/panel:
simple: Add "no-hpd" delay for Innolux TV123WAM").
Fixes: 9c04400f7ea6 ("dt-bindings: drm/panel: Document Innolux TV123WAM panel
bindings")
Signed-off-by: Douglas Anderson
Reviewed-by: Rob Herring
Cc: Sandeep Panda
---
Changes in v2: None
.../{innolux,tv123wam.txt => innolux,p120zdg-bf1.txt} | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
rename Documentation/devicetree/bindings/display/panel/{innolux,tv123wam.txt
=> innolux,p120zdg-bf1.txt} (70%)
diff --git
a/Documentation/devicetree/bindings/display/panel/innolux,tv123wam.txt
b/Documentation/devicetree/bindings/display/panel/innolux,p120zdg-bf1.txt
similarity index 70%
rename from Documentation/devicetree/bindings/display/panel/innolux,tv123wam.txt
rename to
Documentation/devicetree/bindings/display/panel/innolux,p120zdg-bf1.txt
index a9b35265fa13..513f03466aba 100644
--- a/Documentation/devicetree/bindings/display/panel/innolux,tv123wam.txt
+++ b/Documentation/devicetree/bindings/display/panel/innolux,p120zdg-bf1.txt
@@ -1,20 +1,22 @@
-Innolux TV123WAM 12.3 inch eDP 2K display panel
+Innolux P120ZDG-BF1 12.02 inch eDP 2K display panel
This binding is compatible with the simple-panel binding, which is specified
in simple-panel.txt in this directory.
Required properties:
-- compatible: should be "innolux,tv123wam"
+- compatible: should be "innolux,p120zdg-bf1"
- power-supply: regulator to provide the supply voltage
Optional properties:
- enable-gpios: GPIO pin to enable or disable the panel
- backlight: phandle of the backlight device attached to the panel
+- no-hpd: If HPD isn't hooked up; add this property.
Example:
panel_edp: panel-edp {
- compatible = "innolux,tv123wam";
+ compatible = "innolux,p120zdg-bf1";
enable-gpios = < 31 GPIO_ACTIVE_LOW>;
power-supply = <_l2>;
backlight = <>;
+ no-hpd;
};
--
2.19.1.568.g152ad8e336-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/6] dt-bindings: drm/panel: simple: Add no-hpd property
Some eDP panels that are designed to be always connected to a board use their HPD signal to signal that they've finished powering on and they're ready to be talked to. However, for various reasons it's possible that the HPD signal from the panel isn't actually hooked up. In the case where the HPD isn't hooked up you can look at the timing diagram on the panel datasheet and insert a delay for the maximum amount of time that the HPD might take to come up. Let's add a property in the device tree for this concept. Signed-off-by: Douglas Anderson Reviewed-by: Sean Paul Reviewed-by: Rob Herring --- Changes in v2: None .../devicetree/bindings/display/panel/simple-panel.txt | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Documentation/devicetree/bindings/display/panel/simple-panel.txt b/Documentation/devicetree/bindings/display/panel/simple-panel.txt index 45a457ad38f0..b2b872c710f2 100644 --- a/Documentation/devicetree/bindings/display/panel/simple-panel.txt +++ b/Documentation/devicetree/bindings/display/panel/simple-panel.txt @@ -11,6 +11,9 @@ Optional properties: - ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing - enable-gpios: GPIO pin to enable or disable the panel - backlight: phandle of the backlight device attached to the panel +- no-hpd: This panel is supposed to communicate that it's ready via HPD + (hot plug detect) signal, but the signal isn't hooked up so we should + hardcode the max delay from the panel spec when powering up the panel. Example: -- 2.19.1.568.g152ad8e336-goog ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 6/6] drm/panel: simple: Innolux TV123WAM is actually P120ZDG-BF1
As far as I can tell the panel that was added in commit da50bd4258db
("drm/panel: simple: Add Innolux TV123WAM panel driver support")
wasn't actually an Innolux TV123WAM but was actually an Innolux
P120ZDG-BF1.
As far as I can tell the Innolux TV123WAM isn't a real panel and but
it's a mosh between the TI TV123WAM and the Innolux P120ZDG-BF1.
Let's unmosh.
Here's my evidence:
* Searching for TV123WAM on the Internet turns up a TI panel. While
it's possible that an Innolux panel has the same model number as the
TI Panel, it seems a little doubtful. Looking up the datasheet from
the TI Panel shows that it's 1920 x 1280 and 259.2 mm x 172.8 mm.
* As far as I know, the patch adding the Innolux Panel was supposed to
be for the board that's sitting in front of me as I type this
(support for that board is not yet upstream). On the back of that
panel I see Innolux P120ZDZ-EZ1 rev B1.
* Someone pointed me at a datasheet that's supposed to be for the
panel in front of me (sorry, I can't share the datasheet). That
datasheet has the string "p120zdg-bf1"
* If I search for "P120ZDG-BF1" on the Internet I get hits for panels
that are 2160x1440. They don't have datasheets, but the fact that
the resolution matches is a good sign.
In any case, let's update the name and also the physical size to match
the correct panel.
Fixes: da50bd4258db ("drm/panel: simple: Add Innolux TV123WAM panel driver
support")
Signed-off-by: Douglas Anderson
Reviewed-by: Abhinav Kumar
Cc: Sandeep Panda
---
Changes in v2: None
drivers/gpu/drm/panel/panel-simple.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 88592f9a0018..a04ffb3b2174 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1373,7 +1373,7 @@ static const struct panel_desc innolux_n156bge_l21 = {
},
};
-static const struct drm_display_mode innolux_tv123wam_mode = {
+static const struct drm_display_mode innolux_p120zdg_bf1_mode = {
.clock = 206016,
.hdisplay = 2160,
.hsync_start = 2160 + 48,
@@ -1387,13 +1387,13 @@ static const struct drm_display_mode
innolux_tv123wam_mode = {
.flags = DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC,
};
-static const struct panel_desc innolux_tv123wam = {
- .modes = _tv123wam_mode,
+static const struct panel_desc innolux_p120zdg_bf1 = {
+ .modes = _p120zdg_bf1_mode,
.num_modes = 1,
.bpc = 8,
.size = {
- .width = 259,
- .height = 173,
+ .width = 254,
+ .height = 169,
},
.delay = {
.hpd_absent_delay = 200,
@@ -2456,8 +2456,8 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "innolux,n156bge-l21",
.data = _n156bge_l21,
}, {
- .compatible = "innolux,tv123wam",
- .data = _tv123wam,
+ .compatible = "innolux,p120zdg-bf1",
+ .data = _p120zdg_bf1,
}, {
.compatible = "innolux,zj070na-01p",
.data = _zj070na_01p,
--
2.19.1.568.g152ad8e336-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/6] drm/panel: simple: Add "no-hpd" delay for Innolux TV123WAM
If the HPD signal isn't hooked up to this panel we need a 200 ms
delay. In the datasheet this is shown as the maximum time that HPD
will take to be asserted after power is given to the panel.
Signed-off-by: Douglas Anderson
---
Changes in v2:
- Use "hpd_absent_delay" property instead of a bool + prepare delay
drivers/gpu/drm/panel/panel-simple.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 687fd087b9fc..88592f9a0018 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1396,6 +1396,7 @@ static const struct panel_desc innolux_tv123wam = {
.height = 173,
},
.delay = {
+ .hpd_absent_delay = 200,
.unprepare = 500,
},
};
--
2.19.1.568.g152ad8e336-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/i915: Add short HPD IRQ storm detection for non-MST systems
Unfortunately, it seems that the HPD IRQ storm problem from the early
days of Intel GPUs was never entirely solved, only mostly. Within the
last couple of days, I got a bug report from one of our customers who
had been having issues with their machine suddenly booting up very
slowly after having updated. The amount of time it took to boot went
from around 30 seconds, to over 6 minutes consistently.
After some investigation, I discovered that i915 was reporting massive
amounts of short HPD IRQ spam on this system from the DisplayPort port,
despite there not being anything actually connected. The symptoms would
start with one "long" HPD IRQ being detected at boot:
[1.891398] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat
0x0044, dig 0x0044, pins 0x00a0
[1.891436] [drm:intel_hpd_irq_handler [i915]] digital hpd port B - long
[1.891472] [drm:intel_hpd_irq_handler [i915]] Received HPD interrupt on PIN
5 - cnt: 0
[1.891508] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - long
[1.891544] [drm:intel_hpd_irq_handler [i915]] Received HPD interrupt on PIN
7 - cnt: 0
[1.891592] [drm:intel_dp_hpd_pulse [i915]] got hpd irq on port B - long
[1.891628] [drm:intel_dp_hpd_pulse [i915]] got hpd irq on port D - long
…
followed by constant short IRQs afterwards:
[1.895091] [drm:intel_encoder_hotplug [i915]] [CONNECTOR:66:DP-1] status
updated from unknown to disconnected
[1.895129] [drm:i915_hotplug_work_func [i915]] Connector DP-3 (pin 7)
received hotplug event.
[1.895165] [drm:intel_dp_detect [i915]] [CONNECTOR:72:DP-3]
[1.895275] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat
0x0020, dig 0x0020, pins 0x0080
[1.895312] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - short
[1.895762] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat
0x0020, dig 0x0020, pins 0x0080
[1.895799] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - short
[1.896239] [drm:intel_dp_aux_xfer [i915]] dp_aux_ch timeout status
0x71450085
[1.896293] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat
0x0020, dig 0x0020, pins 0x0080
[1.896330] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - short
[1.896781] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat
0x0020, dig 0x0020, pins 0x0080
[1.896817] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - short
[1.897275] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat
0x0020, dig 0x0020, pins 0x0080
The customer's system in question has a GM45 GPU, which is apparently
well known for hotplugging storms.
So, workaround this impressively broken hardware by detecting short IRQ
storms using a separate threshold and count, one that is much higher
then the threshold for long IRQs. We default to a threshold of 50 short
pulses within the timespan of a second, which should amount to about
100ms of constant pulsing. This should be a good middle ground between
avoiding detecting false IRQ storms, while still catching short IRQ
storms quickly enough to minimize the amount of time we'll stutter every
time hotplugging gets re-enabled and immediately disabled by another
short IRQ storm.
And just to be extra safe: we don't enable this by default on systems
with MST support. There's too high of a chance of MST support triggering
storm detection, and systems that are new enough to support MST are a
lot less likely to have issues with IRQ storms anyway.
As a note: this patch was tested using a ThinkPad T450s and a Chamelium
to simulate the short IRQ storms.
Signed-off-by: Lyude Paul
Cc: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_debugfs.c | 89 +++-
drivers/gpu/drm/i915/i915_drv.h | 15 +++--
drivers/gpu/drm/i915/i915_irq.c | 14 -
drivers/gpu/drm/i915/intel_hotplug.c | 84 --
4 files changed, 150 insertions(+), 52 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index b4744a68cd88..84e89fbd55fb 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4566,21 +4566,24 @@ static const struct file_operations i915_forcewake_fops
= {
.release = i915_forcewake_release,
};
-static int i915_hpd_storm_ctl_show(struct seq_file *m, void *data)
+static int i915_hpd_storm_show(struct seq_file *m, bool long_hpd)
{
struct drm_i915_private *dev_priv = m->private;
struct i915_hotplug *hotplug = _priv->hotplug;
+ const unsigned int threshold = long_hpd ?
+ hotplug->long_hpd_storm_threshold :
+ hotplug->short_hpd_storm_threshold;
- seq_printf(m, "Threshold: %d\n", hotplug->hpd_storm_threshold);
+ seq_printf(m, "Threshold: %d\n", threshold);
seq_printf(m, "Detected: %s\n",
yesno(delayed_work_pending(>reenable_work)));
[PATCH 1/2] drm/i915: Fix NULL deref when re-enabling HPD IRQs on systems with MST
Turns out that if you trigger an HPD storm on a system that has an MST
topology connected to it, you'll end up causing the kernel to eventually
hit a NULL deref:
[ 332.339041] BUG: unable to handle kernel NULL pointer dereference at
00ec
[ 332.340906] PGD 0 P4D 0
[ 332.342750] Oops: [#1] SMP PTI
[ 332.344579] CPU: 2 PID: 25 Comm: kworker/2:0 Kdump: loaded Tainted: G
O 4.18.0-rc3short-hpd-storm+ #2
[ 332.346453] Hardware name: LENOVO 20BWS1KY00/20BWS1KY00, BIOS JBET71WW (1.35
) 09/14/2018
[ 332.348361] Workqueue: events intel_hpd_irq_storm_reenable_work [i915]
[ 332.350301] RIP: 0010:intel_hpd_irq_storm_reenable_work.cold.3+0x2f/0x86
[i915]
[ 332.352213] Code: 00 00 ba e8 00 00 00 48 c7 c6 c0 aa 5f a0 48 c7 c7 d0 73
62 a0 4c 89 c1 4c 89 04 24 e8 7f f5 af e0 4c 8b 04 24 44 89 f8 29 e8 <41> 39 80
ec 00 00 00 0f 85 43 13 fc ff 41 0f b6 86 b8 04 00 00 41
[ 332.354286] RSP: 0018:c9147e48 EFLAGS: 00010006
[ 332.356344] RAX: 0005 RBX: 8802c226c9d4 RCX: 0006
[ 332.358404] RDX: RSI: 0082 RDI: 88032dc95570
[ 332.360466] RBP: 0005 R08: R09: 88031b3dc840
[ 332.362528] R10: R11: 00031a069602 R12: 8802c226ca20
[ 332.364575] R13: 8802c2268000 R14: 880310661000 R15: 000a
[ 332.366615] FS: () GS:88032dc8()
knlGS:
[ 332.368658] CS: 0010 DS: ES: CR0: 80050033
[ 332.370690] CR2: 00ec CR3: 0200a003 CR4: 003606e0
[ 332.372724] DR0: DR1: DR2:
[ 332.374773] DR3: DR6: fffe0ff0 DR7: 0400
[ 332.376798] Call Trace:
[ 332.378809] process_one_work+0x1a1/0x350
[ 332.380806] worker_thread+0x30/0x380
[ 332.382777] ? wq_update_unbound_numa+0x10/0x10
[ 332.384772] kthread+0x112/0x130
[ 332.386740] ? kthread_create_worker_on_cpu+0x70/0x70
[ 332.388706] ret_from_fork+0x35/0x40
[ 332.390651] Modules linked in: i915(O) vfat fat joydev btusb btrtl btbcm
btintel bluetooth ecdh_generic iTCO_wdt wmi_bmof i2c_algo_bit drm_kms_helper
intel_rapl syscopyarea sysfillrect x86_pkg_temp_thermal sysimgblt coretemp
fb_sys_fops crc32_pclmul drm psmouse pcspkr mei_me mei i2c_i801 lpc_ich
mfd_core i2c_core tpm_tis tpm_tis_core thinkpad_acpi wmi tpm rfkill video
crc32c_intel serio_raw ehci_pci xhci_pci ehci_hcd xhci_hcd [last unloaded: i915]
[ 332.394963] CR2: 00ec
This appears to be due to the fact that with an MST topology, not all
intel_connector structs will have ->encoder set. So, fix this by
skipping connectors without encoders in
intel_hpd_irq_storm_reenable_work().
For those wondering, this bug was found on accident while simulating HPD
storms using a Chamelium connected to a ThinkPad T450s (Broadwell).
Signed-off-by: Lyude Paul
Cc: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_hotplug.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_hotplug.c
b/drivers/gpu/drm/i915/intel_hotplug.c
index 648a13c6043c..7d21aac10d16 100644
--- a/drivers/gpu/drm/i915/intel_hotplug.c
+++ b/drivers/gpu/drm/i915/intel_hotplug.c
@@ -228,7 +228,8 @@ static void intel_hpd_irq_storm_reenable_work(struct
work_struct *work)
drm_for_each_connector_iter(connector, _iter) {
struct intel_connector *intel_connector =
to_intel_connector(connector);
- if (intel_connector->encoder->hpd_pin == pin) {
+ if (intel_connector->encoder &&
+ intel_connector->encoder->hpd_pin == pin) {
if (connector->polled !=
intel_connector->polled)
DRM_DEBUG_DRIVER("Reenabling HPD on
connector %s\n",
connector->name);
--
2.17.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/2] drm/i915: HPD IRQ storm detection fixes
IMPORTANT - As a note: I have not had the customer who this second patch is for test this yet, I'm sending this ahead of time to make sure this is something that isn't too crazy for upstream to accept. I'm not planning on pushing this after review until I've verified this actually fixes their problems. This series contains a fix for a problem which is very difficult to reproduce under normal circumstances without specialized testing hardware, along with a fix that seems to be required for some especially rebellious GM45 laptops. Lyude Paul (2): drm/i915: Fix NULL deref when re-enabling HPD IRQs on systems with MST drm/i915: Add short HPD IRQ storm detection for non-MST systems drivers/gpu/drm/i915/i915_debugfs.c | 89 +++- drivers/gpu/drm/i915/i915_drv.h | 15 +++-- drivers/gpu/drm/i915/i915_irq.c | 14 - drivers/gpu/drm/i915/intel_hotplug.c | 87 --- 4 files changed, 152 insertions(+), 53 deletions(-) -- 2.17.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/8] dma-buf: remove shared fence staging in reservation object
Quoting Chris Wilson (2018-10-25 21:20:21) > Quoting Chris Wilson (2018-10-25 21:15:17) > > Quoting Christian König (2018-10-04 14:12:43) > > > No need for that any more. Just replace the list when there isn't enough > > > room any more for the additional fence. > > > > Just a heads up. After this series landed, we started hitting a > > use-after-free when iterating the shared list. > > > > <4> [109.613162] general protection fault: [#1] PREEMPT SMP PTI > > <4> [109.613177] CPU: 1 PID: 1357 Comm: gem_busy Tainted: G U > > 4.19.0-rc8-CI-CI_DRM_5035+ #1 > > <4> [109.613189] Hardware name: Dell Inc. XPS 8300 /0Y2MRG, BIOS A06 > > 10/17/2011 > > <4> [109.613252] RIP: 0010:i915_gem_busy_ioctl+0x146/0x380 [i915] > > <4> [109.613261] Code: 0b 43 04 49 83 c6 08 4d 39 e6 89 43 04 74 6d 4d 8b > > 3e e8 5d 54 f4 e0 85 c0 74 0d 80 3d 08 71 1d 00 00 0f 84 bb 00 00 00 31 c0 > > <49> 81 7f 08 20 3a 2c a0 75 cc 41 8b 97 50 02 00 00 49 8b 8f a8 00 > > <4> [109.613283] RSP: 0018:c944bcf8 EFLAGS: 00010246 > > <4> [109.613292] RAX: RBX: c944bdc0 RCX: > > 0001 > > <4> [109.613302] RDX: RSI: RDI: > > 822474a0 > > <4> [109.613311] RBP: c944bd28 R08: 88021e158680 R09: > > 0001 > > <4> [109.613321] R10: 0040 R11: R12: > > 88021e1641b8 > > <4> [109.613331] R13: 0003 R14: 88021e1641b0 R15: > > 6b6b6b6b6b6b6b6b > > <4> [109.613341] FS: 7f9c9fc84980() GS:880227a4() > > knlGS: > > <4> [109.613352] CS: 0010 DS: ES: CR0: 80050033 > > <4> [109.613360] CR2: 7f9c9fcb8000 CR3: 0002247d4005 CR4: > > 000606e0 > > First guess would be > > diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c > index 5fb4fd461908..833698a0d548 100644 > --- a/drivers/dma-buf/reservation.c > +++ b/drivers/dma-buf/reservation.c > @@ -169,7 +169,6 @@ void reservation_object_add_shared_fence(struct > reservation_object *obj, > } > > BUG_ON(fobj->shared_count >= fobj->shared_max); > - fobj->shared_count++; > > replace: > /* > @@ -177,6 +176,8 @@ void reservation_object_add_shared_fence(struct > reservation_object *obj, > * fobj->shared_count is protected by this lock too > */ > RCU_INIT_POINTER(fobj->shared[i], fence); > + if (i == fobj->shared_count) > + fobj->shared_count++; > write_seqcount_end(>seq); > preempt_enable(); > } > > Strictly, perhaps WRITE_ONCE(fobj->shared_count, i + 1); ? Updating shared_count after setting the fence does the trick. -Chris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] drm: tinydrm driver for adafruit PiTFT 3.5" touchscreen
Den 25.10.2018 18.29, skrev Eric Anholt: Eric Anholt writes: I was going to start working on making the vc4 driver work with tinydrm panels, but it turned out tinydrm didn't have the panel I had previously bought. So, last night I ported the fbtft staging driver over to DRM. It seems to work (with DT at https://github.com/anholt/linux/commits/drm-misc-next-hx8357d) -- fbdev works great including rotated, and so does modetest. However, when X11 comes up at 16bpp, I get: https://photos.app.goo.gl/8tuhzPFFoDGamEfk8 If I have tinydrm set a preferred bpp of 24, X looks great. Noralf, any ideas? Also, with these patches and the format modifier patch I just sent, mesa with vc4 is now working with this driver on this branch: https://gitlab.freedesktop.org/anholt/mesa/commits/kmsro Ah, nice to see this happening! Getting hw rendering was one of the advantages I saw DRM could provide over fbdev on these displays. Little did I know how complicated graphics was outside fbdev, so I was unable to realise this myself. The current solution to get hw rendering is to have a userspace process that continously copies the framebuffer: https://github.com/tasanakorn/rpi-fbcp It's used by some of the small DIY handheld game consoles that run emulators which requires hw rendering. Now I wonder how we can improve performance of the SPI updates. At what SPI speed are you running? The datasheet for most of these display controllers list the max speed as 10MHz, but almost all of them can go faster. Some are reported going as high as 70-80MHz. That's for the pixel data transfer, not the commands. tinydrm/mipi-dbi.c sends commands at 10MHz and pixels at full speed (mipi_dbi_spi_cmd_max_speed()). Most panels I have run at 32MHz or 48MHz. Almost all the time is spent in the SPI transfer, so every hz counts. On the Pi there's byte swapping because the DMA capable SPI controller can't do 16-bit (tinydrm_swab16()). If I remember correctly this has negligible impact on performance. The SPI controller/driver on the Pi has some restrictions on the speeds to choose from because the divisor has to be a multiple of two (bcm2835_spi_transfer_one()). A full update on a 320x480 RGB565 panel is 262.5kB, so it's a lot to push over SPI. A 2.8" 320x240 panel is more suitable for video fps, because of the lower resolution. I'll look at the patches during the weekend. Noralf. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108521] RX 580 as eGPU amdgpu: gpu post error!
https://bugs.freedesktop.org/show_bug.cgi?id=108521 --- Comment #17 from Robert Strube --- Created attachment 142203 --> https://bugs.freedesktop.org/attachment.cgi?id=142203=edit lspci *with* eGPU attached at boot -- 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 4/6] drm/bridge: ti-sn65dsi86: Remove the mystery delay
On Mon, Oct 22, 2018 at 01:46:37PM -0700, Douglas Anderson wrote:
> Let's solve the mystery of commit bf1178c98930 ("drm/bridge:
> ti-sn65dsi86: Add mystery delay to enable()"). Specifically the
> reason we needed that mystery delay is that we weren't paying
> attention to HPD.
>
> Looking at the datasheet for the same panel that was tested for the
> original commit, I see there's a timing "t3" that times from power on
> to the aux channel being operational. This time is specced as 0 - 200
> ms. The datasheet says that the aux channel is operational at exactly
> the same time that HPD is asserted.
>
> Scoping the signals on this board showed that HPD was asserted 84 ms
> after power was asserted. That very closely matches the magic 70 ms
> delay that we had. ...and actually, in my testing the 70 ms wasn't
> quite enough of a delay and some percentage of the time the display
> didn't come up until I bumped it to 100 ms (presumably 84 ms would
> have worked too).
>
> To solve this, we tried to hook up the HPD signal in the bridge.
> ...but in doing so we found that that the bridge didn't report that
> HPD was asserted until ~280 ms after we powered it (!). This is
> explained by looking at the sn65dsi86 datasheet section "8.4.5.1 HPD
> (Hot Plug/Unplug Detection)". Reading there we see that the bridge
> isn't even intended to report HPD until 100 ms after it's asserted.
> ...but that would have left us at 184 ms. The extra 100 ms
> (presumably) comes from this part in the datasheet:
>
> > The HPD state machine operates off an internal ring oscillator. The
> > ring oscillator frequency will vary [ ... ]. The min/max range in
> > the HPD State Diagram refers to the possible times based off
> > variation in the ring oscillator frequency.
>
> Given that the 280 ms we'll end up delaying if we hook up HPD is
> _slower_ than the 200 ms we could just hardcode, for now we'll solve
> the problem by just hardcoding a 200 ms delay in the panel driver
> using the patch in this series ("drm/panel: simple: Support panels
> with HPD where HPD isn't connected").
>
> If we later find a panel that needs to use this bridge where we need
> HPD then we'll have to come up with some new code to handle it. Given
> the silly debouncing in the bridge chip, though, it seems unlikely.
>
> One last note is that I tried to solve this through another way: In
> ti_sn_bridge_enable() I tried to use various combinations of
> dp_dpcd_writeb() and dp_dpcd_readb() to detect when the aux channel
> was up. In theory that would let me detect _exactly_ when I could
> continue and do link training. Unfortunately even if I did an aux
> transfer w/out waiting I couldn't see any errors. Possibly I could
> keep looping over link training until it came back with success, but
> that seemed a little overly hacky to me.
>
> Signed-off-by: Douglas Anderson
Awesome commit message and comment, thanks for solving the mystery!
Reviewed-by: Sean Paul
> ---
>
> drivers/gpu/drm/bridge/ti-sn65dsi86.c | 29 +++
> 1 file changed, 16 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> index f8a931cf3665..680566d97adc 100644
> --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> @@ -458,18 +458,6 @@ static void ti_sn_bridge_enable(struct drm_bridge
> *bridge)
> unsigned int val;
> int ret;
>
> - /*
> - * FIXME:
> - * This 70ms was found necessary by experimentation. If it's not
> - * present, link training fails. It seems like it can go anywhere from
> - * pre_enable() up to semi-auto link training initiation below.
> - *
> - * Neither the datasheet for the bridge nor the panel tested mention a
> - * delay of this magnitude in the timing requirements. So for now, add
> - * the mystery delay until someone figures out a better fix.
> - */
> - msleep(70);
> -
> /* DSI_A lane config */
> val = CHA_DSI_LANES(4 - pdata->dsi->lanes);
> regmap_update_bits(pdata->regmap, SN_DSI_LANES_REG,
> @@ -536,7 +524,22 @@ static void ti_sn_bridge_pre_enable(struct drm_bridge
> *bridge)
> /* configure bridge ref_clk */
> ti_sn_bridge_set_refclk_freq(pdata);
>
> - /* in case drm_panel is connected then HPD is not supported */
> + /*
> + * HPD on this bridge chip is a bit useless. This is an eDP bridge
> + * so the HPD is an internal signal that's only there to signal that
> + * the panel is done powering up. ...but the bridge chip debounces
> + * this signal by between 100 ms and 400 ms (depending on process,
> + * voltage, and temperate--I measured it at about 200 ms). One
> + * particular panel asserted HPD 84 ms after it was powered on meaning
> + * that we saw HPD 284 ms after power on. ...but the same panel said
> + * that instead of looking at HPD you could just
Re: [PATCH v5 3/4] drm: Document variable refresh properties
On 2018-10-12 12:44 p.m., Nicholas Kazlauskas wrote: > These include the drm_connector 'vrr_capable' and the drm_crtc > 'vrr_enabled' properties. > > Signed-off-by: Nicholas Kazlauskas > --- > Documentation/gpu/drm-kms.rst | 7 +++ > drivers/gpu/drm/drm_connector.c | 22 ++ > 2 files changed, 29 insertions(+) > > diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst > index 4b1501b4835b..8da2a178cf85 100644 > --- a/Documentation/gpu/drm-kms.rst > +++ b/Documentation/gpu/drm-kms.rst > @@ -575,6 +575,13 @@ Explicit Fencing Properties > .. kernel-doc:: drivers/gpu/drm/drm_atomic_uapi.c > :doc: explicit fencing properties > > + > +Variable Refresh Properties > +--- > + > +.. kernel-doc:: drivers/gpu/drm/drm_connector.c > + :doc: Variable refresh properties > + > Existing KMS Properties > --- > > diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c > index f0deeb7298d0..2a12853ca917 100644 > --- a/drivers/gpu/drm/drm_connector.c > +++ b/drivers/gpu/drm/drm_connector.c > @@ -1254,6 +1254,28 @@ int drm_mode_create_scaling_mode_property(struct > drm_device *dev) > } > EXPORT_SYMBOL(drm_mode_create_scaling_mode_property); > > +/** > + * DOC: Variable refresh properties > + * > + * Variable refresh rate control is supported via properties on the > + * _connector and _crtc objects. > + * > + * "vrr_capable": > + * Optional _connector boolean property that drivers should attach > + * with drm_connector_attach_vrr_capable_property() on connectors that > + * could support variable refresh rates. Drivers should update the > + * property value by calling drm_connector_set_vrr_capable_property(). > + * > + * Absence of the property should indicate absence of support. > + * > + * "vrr_enabled": > + * Default _crtc boolean property that notifies the driver that the > + * variable refresh rate adjustment should be enabled for the CRTC. > + * > + * Support for variable refresh rate will depend on the "vrr_capable" > + * property exposed on the _connector object. We probably want to make it clear that this is a content hint. Maybe something like: * "vrr_enabled": * Default _crtc boolean property that notifies the driver that the * content on the CRTC is suitable for variable refresh presentation. * The driver will take that as a hint to enable variable refresh rate * if the receiver supports it, i.e. the "vrr_capable" property on the * _connector_object is true. Harry > + */ > + > /** > * drm_connector_attach_vrr_capable_property - creates the > * vrr_capable property > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH -next] drm/amd/powerplay: remove duplicated includes
On Sun, Oct 21, 2018 at 11:32 PM YueHaibing wrote: > > Remove some duplicated include. > > Signed-off-by: YueHaibing Applied. Thanks! Alex > --- > drivers/gpu/drm/amd/powerplay/inc/hwmgr.h | 1 - > drivers/gpu/drm/amd/powerplay/inc/smu7_common.h | 4 > drivers/gpu/drm/amd/powerplay/smumgr/polaris10_smumgr.c | 1 - > drivers/gpu/drm/amd/powerplay/smumgr/smu10_smumgr.c | 1 - > drivers/gpu/drm/amd/powerplay/smumgr/vegam_smumgr.c | 1 - > 5 files changed, 8 deletions(-) > > diff --git a/drivers/gpu/drm/amd/powerplay/inc/hwmgr.h > b/drivers/gpu/drm/amd/powerplay/inc/hwmgr.h > index e5a60aa..07d180ce 100644 > --- a/drivers/gpu/drm/amd/powerplay/inc/hwmgr.h > +++ b/drivers/gpu/drm/amd/powerplay/inc/hwmgr.h > @@ -28,7 +28,6 @@ > #include "hardwaremanager.h" > #include "hwmgr_ppt.h" > #include "ppatomctrl.h" > -#include "hwmgr_ppt.h" > #include "power_state.h" > #include "smu_helper.h" > > diff --git a/drivers/gpu/drm/amd/powerplay/inc/smu7_common.h > b/drivers/gpu/drm/amd/powerplay/inc/smu7_common.h > index 65eb630..94bf7b6 100644 > --- a/drivers/gpu/drm/amd/powerplay/inc/smu7_common.h > +++ b/drivers/gpu/drm/amd/powerplay/inc/smu7_common.h > @@ -40,10 +40,6 @@ > #include "bif/bif_5_0_d.h" > #include "bif/bif_5_0_sh_mask.h" > > - > -#include "bif/bif_5_0_d.h" > -#include "bif/bif_5_0_sh_mask.h" > - > #include "dce/dce_10_0_d.h" > #include "dce/dce_10_0_sh_mask.h" > > diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/polaris10_smumgr.c > b/drivers/gpu/drm/amd/powerplay/smumgr/polaris10_smumgr.c > index 872d382..2b2c266 100644 > --- a/drivers/gpu/drm/amd/powerplay/smumgr/polaris10_smumgr.c > +++ b/drivers/gpu/drm/amd/powerplay/smumgr/polaris10_smumgr.c > @@ -44,7 +44,6 @@ > > #include "smu7_hwmgr.h" > #include "hardwaremanager.h" > -#include "ppatomctrl.h" > #include "atombios.h" > #include "pppcielanes.h" > > diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/smu10_smumgr.c > b/drivers/gpu/drm/amd/powerplay/smumgr/smu10_smumgr.c > index d0eb8ab..d111dd4 100644 > --- a/drivers/gpu/drm/amd/powerplay/smumgr/smu10_smumgr.c > +++ b/drivers/gpu/drm/amd/powerplay/smumgr/smu10_smumgr.c > @@ -29,7 +29,6 @@ > #include "rv_ppsmc.h" > #include "smu10_driver_if.h" > #include "smu10.h" > -#include "ppatomctrl.h" > #include "pp_debug.h" > > > diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/vegam_smumgr.c > b/drivers/gpu/drm/amd/powerplay/smumgr/vegam_smumgr.c > index 9f71512..1e69300 100644 > --- a/drivers/gpu/drm/amd/powerplay/smumgr/vegam_smumgr.c > +++ b/drivers/gpu/drm/amd/powerplay/smumgr/vegam_smumgr.c > @@ -40,7 +40,6 @@ > > #include "smu7_hwmgr.h" > #include "hardwaremanager.h" > -#include "ppatomctrl.h" > #include "atombios.h" > #include "pppcielanes.h" > > -- > 1.8.3.1 > > > ___ > amd-gfx mailing list > amd-...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/amd-gfx ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 5/6] drm/panel: simple: Innolux TV123WAM is actually P120ZDG-BF1
On 2018-10-25 11:45, Doug Anderson wrote:
Hi,
On Thu, Oct 25, 2018 at 11:13 AM Sean Paul wrote:
On Mon, Oct 22, 2018 at 01:46:38PM -0700, Douglas Anderson wrote:
> As far as I can tell the panel that was added in commit da50bd4258db
> ("drm/panel: simple: Add Innolux TV123WAM panel driver support")
> wasn't actually an Innolux TV123WAM but was actually an Innolux
> P120ZDG-BF1.
>
> As far as I can tell the Innolux TV123WAM isn't a real panel and but
> it's a mosh between the TI TV123WAM and the Innolux P120ZDG-BF1.
> Let's unmosh.
>
> Here's my evidence:
>
> * Searching for TV123WAM on the Internet turns up a TI panel. While
> it's possible that an Innolux panel has the same model number as the
> TI Panel, it seems a little doubtful. Looking up the datasheet from
> the TI Panel shows that it's 1920 x 1280 and 259.2 mm x 172.8 mm.
>
> * As far as I know, the patch adding the Innolux Panel was supposed to
> be for the board that's sitting in front of me as I type this
> (support for that board is not yet upstream). On the back of that
> panel I see Innolux P120ZDZ-EZ1 rev B1.
>
> * Someone pointed me at a datasheet that's supposed to be for the
> panel in front of me (sorry, I can't share the datasheet). That
> datasheet has the string "p120zdg-bf1"
>
> * If I search for "P120ZDG-BF1" on the Internet I get hits for panels
> that are 2160x1440. They don't have datasheets, but the fact that
> the resolution matches is a good sign.
>
> In any case, let's update the name and also the physical size to match
> the correct panel.
>
> Fixes: da50bd4258db ("drm/panel: simple: Add Innolux TV123WAM panel driver
support")
> Signed-off-by: Douglas Anderson
> Cc: Sandeep Panda
> ---
If Rob is onboard with this binding change, please feel free to add
Reviewed-by: Abhinav Kumar
>
> drivers/gpu/drm/panel/panel-simple.c | 14 +++---
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
> index 937e97490c30..7ee1abc5d81b 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -1370,7 +1370,7 @@ static const struct panel_desc innolux_n156bge_l21 = {
> },
> };
>
> -static const struct drm_display_mode innolux_tv123wam_mode = {
> +static const struct drm_display_mode innolux_p120zdg_bf1_mode = {
> .clock = 206016,
> .hdisplay = 2160,
> .hsync_start = 2160 + 48,
> @@ -1384,13 +1384,13 @@ static const struct drm_display_mode
innolux_tv123wam_mode = {
> .flags = DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC,
> };
>
> -static const struct panel_desc innolux_tv123wam = {
> - .modes = _tv123wam_mode,
> +static const struct panel_desc innolux_p120zdg_bf1 = {
> + .modes = _p120zdg_bf1_mode,
> .num_modes = 1,
> .bpc = 8,
> .size = {
> - .width = 259,
> - .height = 173,
> + .width = 254,
> + .height = 169,
> },
> .delay = {
> .prepare = 200,
> @@ -2454,8 +2454,8 @@ static const struct of_device_id platform_of_match[] = {
> .compatible = "innolux,n156bge-l21",
> .data = _n156bge_l21,
> }, {
> - .compatible = "innolux,tv123wam",
I think we should update the struct, but we might want to keep this
around.
Given the tv123wam panel is TI, we're likely not going to have a
collision on
innolux,...
That said, I'll defer to robh on this one, I'm not sure if changing
names is
cool once the bindings have hit mainline.
Whoops, I missed Rob on this patch--just had him on the bindings one.
...generally I believe Rob seems to be OK with wiping out backward
compatibility for things like this when the previous binding is super
new and there's no evidence that anyone ever used it (like if it was
added for a specific board and that board doesn't have a fully
functional DT anyway).
In this particular case I'm 99.% certain nobody is using the
existing binding. If someone crawls out of the woodwork and says this
patch broke them, it would be trivially easy to add the backward
compatible string later.
Obviously Rob can feel free to correct me if I'm wrong.
I purposely put this patch at the end of the series so we can land the
earlier ones and we can sit on this one for a little while if desired.
-Doug
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108542] hdmi issues with kernel 4.18
https://bugs.freedesktop.org/show_bug.cgi?id=108542 --- Comment #2 from davide26...@gmail.com --- Created attachment 142207 --> https://bugs.freedesktop.org/attachment.cgi?id=142207=edit dmesg -- 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 v6 26/28] drm/i915/dsc: Enable and disable appropriate power wells for VDSC
On Thu, Oct 25, 2018 at 05:22:18PM +0300, Ville Syrjälä wrote:
> On Wed, Oct 24, 2018 at 03:28:38PM -0700, Manasi Navare wrote:
> > A separate power well 2 (PG2) is required for VDSC on eDP transcoder
> > whereas all other transcoders use the power wells associated with the
> > transcoders for VDSC.
> > This patch adds a helper to obtain correct power domain depending on
> > transcoder being used and enables/disables the power wells during
> > VDSC enabling/disabling.
> >
> > v2:
> > * Fix tabs, const crtc_state, fix comments (Ville)
> >
> > Suggested-by: Ville Syrjala
> > Cc: Ville Syrjala
> > Cc: Imre Deak
> > Cc: Rodrigo Vivi
> > Signed-off-by: Manasi Navare
> > Reviewed-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/intel_vdsc.c | 26 ++
> > 1 file changed, 26 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_vdsc.c
> > b/drivers/gpu/drm/i915/intel_vdsc.c
> > index 5e76b4a44d90..0fed36e2491a 100644
> > --- a/drivers/gpu/drm/i915/intel_vdsc.c
> > +++ b/drivers/gpu/drm/i915/intel_vdsc.c
> > @@ -581,6 +581,24 @@ int intel_dp_compute_dsc_params(struct intel_dp
> > *intel_dp,
> > return 0;
> > }
> >
> > +static enum intel_display_power_domain
> > +intel_dsc_get_power_domains(const struct intel_crtc_state *crtc_state)
>
> intel_dsc_power_domain() or something like that to match
> the naming convention introduced by intel_ddi_main_link_aux_domain()?
Ok i can rename to use intel_dsc_power_domain() but it should still live
in intel_vdsc.c right?
>
> Oh, and we'll need to update intel_ddi_get_power_domains() as well.
We would need to add this power domain here so that its obtained during
the intel_modeset_setup_hw_state()..?
Manasi
>
> > +{
> > + enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
> > +
> > + /*
> > +* On ICL VDSC/joining for eDP transcoder uses a separate power well PW2
> > +* This requires POWER_DOMAIN_TRANSCODER_EDP_VDSC power domain.
> > +* For any other transcoder, VDSC/joining uses the power well associated
> > +* with the pipe/transcoder in use. Hence another reference on the
> > +* transcoder power domain will suffice.
> > +*/
> > + if (cpu_transcoder == TRANSCODER_EDP)
> > + return POWER_DOMAIN_TRANSCODER_EDP_VDSC;
> > + else
> > + return POWER_DOMAIN_TRANSCODER(cpu_transcoder);
> > +}
> > +
> > static void intel_configure_pps_for_dsc_encoder(struct intel_encoder
> > *encoder,
> > struct intel_crtc_state
> > *crtc_state)
> > {
> > @@ -1020,6 +1038,10 @@ void intel_dsc_enable(struct intel_encoder *encoder,
> > if (!crtc_state->dsc_params.compression_enable)
> > return;
> >
> > + /* Enable Power wells for VDSC/joining */
> > + intel_display_power_get(dev_priv,
> > + intel_dsc_get_power_domains(crtc_state));
> > +
> > intel_configure_pps_for_dsc_encoder(encoder, crtc_state);
> >
> > intel_dp_send_dsc_pps_sdp(encoder, crtc_state);
> > @@ -1074,4 +1096,8 @@ void intel_dsc_disable(struct intel_encoder *encoder,
> > RIGHT_BRANCH_VDSC_ENABLE);
> > I915_WRITE(dss_ctl2_reg, dss_ctl2_val);
> >
> > + /* Disable Power wells for VDSC/joining */
> > + intel_display_power_put(dev_priv,
> > + intel_dsc_get_power_domains(old_crtc_state));
> > +
>
> Bogus newline here.
>
> > }
> > --
> > 2.18.0
>
> --
> Ville Syrjälä
> Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 18/28] drm/i915/dp: Enable/Disable DSC in DP Sink
On Thu, Oct 25, 2018 at 05:03:06PM +0300, Ville Syrjälä wrote:
> On Wed, Oct 24, 2018 at 03:28:30PM -0700, Manasi Navare wrote:
> > From: Gaurav K Singh
> >
> > This patch enables decompression support in sink device
> > before link training and disables the same during the
> > DDI disabling.
> >
> > v2:(From Manasi)
> > * Change the enable/disable function to take crtc_state
> > instead of intel_dp as an argument (Manasi)
> > * Use the compression_enable flag as part of crtc_state (Manasi)
> >
> > Cc: Jani Nikula
> > Cc: Ville Syrjala
> > Cc: Anusha Srivatsa
> > Cc: Gaurav K Singh
> > Signed-off-by: Gaurav K Singh
> > Signed-off-by: Manasi Navare
> > Reviewed-by: Anusha Srivatsa
> > ---
> > drivers/gpu/drm/i915/intel_ddi.c | 5 +
> > drivers/gpu/drm/i915/intel_dp.c | 15 +++
> > drivers/gpu/drm/i915/intel_drv.h | 3 +++
> > 3 files changed, 23 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> > b/drivers/gpu/drm/i915/intel_ddi.c
> > index e40a8c97d34b..1de0a3917d7f 100644
> > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > @@ -2930,6 +2930,8 @@ static void intel_ddi_pre_enable_dp(struct
> > intel_encoder *encoder,
> > intel_ddi_init_dp_buf_reg(encoder);
> > if (!is_mst)
> > intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
> > + intel_dp_sink_set_decompression_state(intel_dp, crtc_state,
> > + DP_DECOMPRESSION_EN);
> > intel_dp_start_link_train(intel_dp);
> > if (port != PORT_A || INTEL_GEN(dev_priv) >= 9)
> > intel_dp_stop_link_train(intel_dp);
> > @@ -3272,6 +3274,9 @@ static void intel_disable_ddi_dp(struct intel_encoder
> > *encoder,
> > intel_edp_drrs_disable(intel_dp, old_crtc_state);
> > intel_psr_disable(intel_dp, old_crtc_state);
> > intel_edp_backlight_off(old_conn_state);
> > + /* Disable the decompression in DP Sink */
> > + intel_dp_sink_set_decompression_state(intel_dp, old_crtc_state,
> > + ~DP_DECOMPRESSION_EN);
>
> That looks suspicious.
>
> I can't figure out what value you're actually passing here since I
> can't find the definiiton of DP_DECOMPRESSION_EN anywhere.
This is defined in /include/drm/drm_dp_helper.h
Manasi
>
> > }
> >
> > static void intel_disable_ddi_hdmi(struct intel_encoder *encoder,
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index 35162c3bc811..72e6605f0ed7 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -3005,6 +3005,21 @@ static bool downstream_hpd_needs_d0(struct intel_dp
> > *intel_dp)
> > intel_dp->downstream_ports[0] & DP_DS_PORT_HPD;
> > }
> >
> > +void intel_dp_sink_set_decompression_state(struct intel_dp *intel_dp,
> > + const struct intel_crtc_state
> > *crtc_state,
> > + int state)
> > +{
> > + int ret;
> > +
> > + if (!crtc_state->dsc_params.compression_enable)
> > + return;
> > +
> > + ret = drm_dp_dpcd_writeb(_dp->aux, DP_DSC_ENABLE, state);
> > + if (ret < 0)
> > + DRM_DEBUG_KMS("Failed to %s sink decompression state\n",
> > + state == DP_DECOMPRESSION_EN ? "enable" :
> > "disable");
> > +}
> > +
> > /* If the sink supports it, try to set the power state appropriately */
> > void intel_dp_sink_dpms(struct intel_dp *intel_dp, int mode)
> > {
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > b/drivers/gpu/drm/i915/intel_drv.h
> > index c4be4ba7adac..4f5d17bcd54e 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -1786,6 +1786,9 @@ void intel_dp_stop_link_train(struct intel_dp
> > *intel_dp);
> > int intel_dp_retrain_link(struct intel_encoder *encoder,
> > struct drm_modeset_acquire_ctx *ctx);
> > void intel_dp_sink_dpms(struct intel_dp *intel_dp, int mode);
> > +void intel_dp_sink_set_decompression_state(struct intel_dp *intel_dp,
> > + const struct intel_crtc_state
> > *crtc_state,
> > + int state);
> > void intel_dp_encoder_reset(struct drm_encoder *encoder);
> > void intel_dp_encoder_suspend(struct intel_encoder *intel_encoder);
> > void intel_dp_encoder_destroy(struct drm_encoder *encoder);
> > --
> > 2.18.0
>
> --
> Ville Syrjälä
> Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 27/28] drm/i915/dsc: Add Per connector debugfs node for DSC support/enable
On Wed, Oct 24, 2018 at 06:28:02PM -0400, Lyude Paul wrote:
> On Wed, 2018-10-24 at 15:28 -0700, Manasi Navare wrote:
> > DSC can be supported per DP connector. This patch adds a per connector
> > debugfs node to expose DSC support capability by the kernel.
> > The same node can be used from userspace to force DSC enable.
> >
> > v2:
> > * Use kstrtobool_from_user to avoid explicit error checking (Lyude)
> > * Rebase on drm-tip (Manasi)
> >
> > Cc: Rodrigo Vivi
> > Cc: Ville Syrjala
> > Cc: Anusha Srivatsa
> > Cc: Lyude Paul
> > Signed-off-by: Manasi Navare
> > Reviewed-by: Lyude Paul
>
> (just making a note to anyone passing by this: my R-B here is still valid!)
> (also thanks for the patch :)
Thanks Lyude for thsi note and the initial review feedback! Appreciate your
time and inputs.
Manasi
> > ---
> > drivers/gpu/drm/i915/i915_debugfs.c | 71 -
> > drivers/gpu/drm/i915/intel_dp.c | 1 +
> > drivers/gpu/drm/i915/intel_drv.h| 3 ++
> > 3 files changed, 74 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> > b/drivers/gpu/drm/i915/i915_debugfs.c
> > index 5cadfcd03ea9..6e631f08dd4b 100644
> > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > @@ -4999,6 +4999,72 @@ static int i915_hdcp_sink_capability_show(struct
> > seq_file *m, void *data)
> > }
> > DEFINE_SHOW_ATTRIBUTE(i915_hdcp_sink_capability);
> >
> > +static int i915_dsc_support_show(struct seq_file *m, void *data)
> > +{
> > + struct drm_connector *connector = m->private;
> > + struct intel_encoder *encoder = intel_attached_encoder(connector);
> > + struct intel_dp *intel_dp =
> > + enc_to_intel_dp(>base);
> > + struct intel_crtc *crtc;
> > + struct intel_crtc_state *crtc_state;
> > +
> > + crtc = to_intel_crtc(encoder->base.crtc);
> > + crtc_state = to_intel_crtc_state(crtc->base.state);
> > + drm_modeset_lock(>base.mutex, NULL);
> > + seq_printf(m, "Enabled: %s\n",
> > + yesno(crtc_state->dsc_params.compression_enable));
> > + seq_printf(m, "Supported: %s\n",
> > + yesno(drm_dp_sink_supports_dsc(intel_dp->dsc_dpcd)));
> > + drm_modeset_unlock(>base.mutex);
> > +
> > + return 0;
> > +}
> > +
> > +static ssize_t i915_dsc_support_write(struct file *file,
> > + const char __user *ubuf,
> > + size_t len, loff_t *offp)
> > +{
> > + bool dsc_enable = false;
> > + int ret;
> > + struct drm_connector *connector =
> > + ((struct seq_file *)file->private_data)->private;
> > + struct intel_encoder *encoder = intel_attached_encoder(connector);
> > + struct intel_dp *intel_dp = enc_to_intel_dp(>base);
> > +
> > + if (len == 0)
> > + return 0;
> > +
> > + DRM_DEBUG_DRIVER("Copied %d bytes from user to force DSC\n",
> > +(unsigned int)len);
> > +
> > + ret = kstrtobool_from_user(ubuf, len, _enable);
> > + if (ret < 0)
> > + return ret;
> > +
> > + DRM_DEBUG_DRIVER("Got %s for DSC Enable\n",
> > +(dsc_enable) ? "true" : "false");
> > + intel_dp->force_dsc_en = dsc_enable;
> > +
> > + *offp += len;
> > + return len;
> > +}
> > +
> > +static int i915_dsc_support_open(struct inode *inode,
> > +struct file *file)
> > +{
> > + return single_open(file, i915_dsc_support_show,
> > + inode->i_private);
> > +}
> > +
> > +static const struct file_operations i915_dsc_support_fops = {
> > + .owner = THIS_MODULE,
> > + .open = i915_dsc_support_open,
> > + .read = seq_read,
> > + .llseek = seq_lseek,
> > + .release = single_release,
> > + .write = i915_dsc_support_write
> > +};
> > +
> > /**
> > * i915_debugfs_connector_add - add i915 specific connector debugfs files
> > * @connector: pointer to a registered drm_connector
> > @@ -5017,9 +5083,12 @@ int i915_debugfs_connector_add(struct drm_connector
> > *connector)
> > return -ENODEV;
> >
> > if (connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort ||
> > - connector->connector_type == DRM_MODE_CONNECTOR_eDP)
> > + connector->connector_type == DRM_MODE_CONNECTOR_eDP) {
> > debugfs_create_file("i915_dpcd", S_IRUGO, root,
> > connector, _dpcd_fops);
> > + debugfs_create_file("i915_dsc_support", S_IRUGO, root,
> > + connector, _dsc_support_fops);
> > + }
> >
> > if (connector->connector_type == DRM_MODE_CONNECTOR_eDP) {
> > debugfs_create_file("i915_panel_timings", S_IRUGO, root,
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index 72e6605f0ed7..0b5939992c2b 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -2287,6 +2287,7 @@ intel_dp_compute_config(struct intel_encoder *encoder,
> >
[PATCH v2 3/9] drm/hisilicon/kirin: Use drm_fbdev_generic_setup()
The CMA helper is already using the drm_fb_helper_generic_probe part of
the generic fbdev emulation. This patch makes full use of the generic
fbdev emulation by using its drm_client callbacks. This means that
drm_mode_config_funcs->output_poll_changed and drm_driver->lastclose are
now handled by the emulation code. Additionally fbdev unregister happens
automatically on drm_dev_unregister().
The drm_fbdev_generic_setup() call is put after drm_dev_register() in the
driver. This is done to highlight the fact that fbdev emulation is an
internal client that makes use of the driver, it is not part of the
driver as such. If fbdev setup fails, an error is printed, but the driver
succeeds probing.
struct kirin_drm_private can be removed now that driver doesn't have to
store the fbdev pointer.
Cc: Xinliang Liu
Cc: Rongrong Zou
Cc: Xinwei Kong
Cc: Chen Feng
Signed-off-by: Noralf Trønnes
Acked-by: Sam Ravnborg
---
drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 38 ++---
drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h | 4 ---
2 files changed, 3 insertions(+), 39 deletions(-)
diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
index e6a62d5a00a3..15e32e5d9101 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -33,32 +34,15 @@ static struct kirin_dc_ops *dc_ops;
static int kirin_drm_kms_cleanup(struct drm_device *dev)
{
- struct kirin_drm_private *priv = dev->dev_private;
-
- if (priv->fbdev) {
- drm_fbdev_cma_fini(priv->fbdev);
- priv->fbdev = NULL;
- }
-
drm_kms_helper_poll_fini(dev);
dc_ops->cleanup(to_platform_device(dev->dev));
drm_mode_config_cleanup(dev);
- devm_kfree(dev->dev, priv);
- dev->dev_private = NULL;
return 0;
}
-static void kirin_fbdev_output_poll_changed(struct drm_device *dev)
-{
- struct kirin_drm_private *priv = dev->dev_private;
-
- drm_fbdev_cma_hotplug_event(priv->fbdev);
-}
-
static const struct drm_mode_config_funcs kirin_drm_mode_config_funcs = {
.fb_create = drm_gem_fb_create,
- .output_poll_changed = kirin_fbdev_output_poll_changed,
.atomic_check = drm_atomic_helper_check,
.atomic_commit = drm_atomic_helper_commit,
};
@@ -76,14 +60,8 @@ static void kirin_drm_mode_config_init(struct drm_device
*dev)
static int kirin_drm_kms_init(struct drm_device *dev)
{
- struct kirin_drm_private *priv;
int ret;
- priv = devm_kzalloc(dev->dev, sizeof(*priv), GFP_KERNEL);
- if (!priv)
- return -ENOMEM;
-
- dev->dev_private = priv;
dev_set_drvdata(dev->dev, dev);
/* dev->mode_config initialization */
@@ -117,26 +95,14 @@ static int kirin_drm_kms_init(struct drm_device *dev)
/* init kms poll for handling hpd */
drm_kms_helper_poll_init(dev);
- priv->fbdev = drm_fbdev_cma_init(dev, 32,
-dev->mode_config.num_connector);
-
- if (IS_ERR(priv->fbdev)) {
- DRM_ERROR("failed to initialize fbdev.\n");
- ret = PTR_ERR(priv->fbdev);
- goto err_cleanup_poll;
- }
return 0;
-err_cleanup_poll:
- drm_kms_helper_poll_fini(dev);
err_unbind_all:
component_unbind_all(dev->dev, dev);
err_dc_cleanup:
dc_ops->cleanup(to_platform_device(dev->dev));
err_mode_config_cleanup:
drm_mode_config_cleanup(dev);
- devm_kfree(dev->dev, priv);
- dev->dev_private = NULL;
return ret;
}
@@ -199,6 +165,8 @@ static int kirin_drm_bind(struct device *dev)
if (ret)
goto err_kms_cleanup;
+ drm_fbdev_generic_setup(drm_dev, 32);
+
return 0;
err_kms_cleanup:
diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h
b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h
index 56cb62df065c..ad027d1cc826 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h
@@ -19,10 +19,6 @@ struct kirin_dc_ops {
void (*cleanup)(struct platform_device *pdev);
};
-struct kirin_drm_private {
- struct drm_fbdev_cma *fbdev;
-};
-
extern const struct kirin_dc_ops ade_dc_ops;
#endif /* __KIRIN_DRM_DRV_H__ */
--
2.15.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 4/9] drm/mxsfb: Use drm_fbdev_generic_setup()
The CMA helper is already using the drm_fb_helper_generic_probe part of
the generic fbdev emulation. This patch makes full use of the generic
fbdev emulation by using its drm_client callbacks. This means that
drm_mode_config_funcs->output_poll_changed and drm_driver->lastclose are
now handled by the emulation code. Additionally fbdev unregister happens
automatically on drm_dev_unregister().
The drm_fbdev_generic_setup() call is put after drm_dev_register() in the
driver. This is done to highlight the fact that fbdev emulation is an
internal client that makes use of the driver, it is not part of the
driver as such. If fbdev setup fails, an error is printed, but the driver
succeeds probing.
Cc: Marek Vasut
Signed-off-by: Noralf Trønnes
Acked-by: Sam Ravnborg
---
drivers/gpu/drm/mxsfb/mxsfb_drv.c | 26 ++
drivers/gpu/drm/mxsfb/mxsfb_drv.h | 1 -
2 files changed, 2 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
index 2393e6d16ffd..3a8cc4226a4b 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
@@ -263,23 +263,12 @@ static int mxsfb_load(struct drm_device *drm, unsigned
long flags)
drm_kms_helper_poll_init(drm);
- mxsfb->fbdev = drm_fbdev_cma_init(drm, 32,
- drm->mode_config.num_connector);
- if (IS_ERR(mxsfb->fbdev)) {
- ret = PTR_ERR(mxsfb->fbdev);
- mxsfb->fbdev = NULL;
- dev_err(drm->dev, "Failed to init FB CMA area\n");
- goto err_cma;
- }
-
platform_set_drvdata(pdev, drm);
drm_helper_hpd_irq_event(drm);
return 0;
-err_cma:
- drm_irq_uninstall(drm);
err_irq:
drm_panel_detach(mxsfb->panel);
err_vblank:
@@ -290,11 +279,6 @@ static int mxsfb_load(struct drm_device *drm, unsigned
long flags)
static void mxsfb_unload(struct drm_device *drm)
{
- struct mxsfb_drm_private *mxsfb = drm->dev_private;
-
- if (mxsfb->fbdev)
- drm_fbdev_cma_fini(mxsfb->fbdev);
-
drm_kms_helper_poll_fini(drm);
drm_mode_config_cleanup(drm);
@@ -307,13 +291,6 @@ static void mxsfb_unload(struct drm_device *drm)
pm_runtime_disable(drm->dev);
}
-static void mxsfb_lastclose(struct drm_device *drm)
-{
- struct mxsfb_drm_private *mxsfb = drm->dev_private;
-
- drm_fbdev_cma_restore_mode(mxsfb->fbdev);
-}
-
static void mxsfb_irq_preinstall(struct drm_device *drm)
{
struct mxsfb_drm_private *mxsfb = drm->dev_private;
@@ -347,7 +324,6 @@ static struct drm_driver mxsfb_driver = {
.driver_features= DRIVER_GEM | DRIVER_MODESET |
DRIVER_PRIME | DRIVER_ATOMIC |
DRIVER_HAVE_IRQ,
- .lastclose = mxsfb_lastclose,
.irq_handler= mxsfb_irq_handler,
.irq_preinstall = mxsfb_irq_preinstall,
.irq_uninstall = mxsfb_irq_preinstall,
@@ -412,6 +388,8 @@ static int mxsfb_probe(struct platform_device *pdev)
if (ret)
goto err_unload;
+ drm_fbdev_generic_setup(drm, 32);
+
return 0;
err_unload:
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.h
b/drivers/gpu/drm/mxsfb/mxsfb_drv.h
index 5d0883fc805b..bedd6801edca 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_drv.h
+++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.h
@@ -37,7 +37,6 @@ struct mxsfb_drm_private {
struct drm_simple_display_pipe pipe;
struct drm_connectorconnector;
struct drm_panel*panel;
- struct drm_fbdev_cma*fbdev;
};
int mxsfb_setup_crtc(struct drm_device *dev);
--
2.15.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 0/9] drm/cma-helper drivers: Use drm_fbdev_generic_setup()
This patchset moves the drivers using the CMA helper fully over to the generic fbdev emulation. These are the remaining patches that didn't get a driver maintainer ack or has been rebased. For context, this is part 1 of the generic fbdev emulation: drm: Add generic fbdev emulation https://patchwork.freedesktop.org/series/45848/ Noralf. Cc: Alexey Brodkin Cc: Stefan Agner Cc: Xinliang Liu Cc: Rongrong Zou Cc: Xinwei Kong Cc: Chen Feng Cc: Marek Vasut Cc: Laurent Pinchart Cc: Boris Brezillon Cc: Maxime Ripard Cc: Jyri Sarha Cc: Tomi Valkeinen Noralf Trønnes (9): drm/arc: Use drm_fbdev_generic_setup() drm/fsl-dcu: Use drm_fbdev_generic_setup() drm/hisilicon/kirin: Use drm_fbdev_generic_setup() drm/mxsfb: Use drm_fbdev_generic_setup() drm/rcar-du: Use drm_fbdev_generic_setup() drm/atmel-hlcdc: Use drm_fbdev_generic_setup() drm/sun4i: Use drm_fbdev_generic_setup() drm/tilcdc: Use drm_fbdev_generic_setup() drm/cma-helper: Remove unused fbdev code drivers/gpu/drm/Kconfig | 4 - drivers/gpu/drm/arc/arcpgu.h| 4 - drivers/gpu/drm/arc/arcpgu_drv.c| 33 +- drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c| 7 +- drivers/gpu/drm/drm_fb_cma_helper.c | 130 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 25 + drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h | 1 - drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 38 +-- drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h | 4 - drivers/gpu/drm/mxsfb/mxsfb_drv.c | 26 + drivers/gpu/drm/mxsfb/mxsfb_drv.h | 1 - drivers/gpu/drm/rcar-du/rcar_du_drv.c | 15 +-- drivers/gpu/drm/rcar-du/rcar_du_drv.h | 2 - drivers/gpu/drm/rcar-du/rcar_du_kms.c | 21 drivers/gpu/drm/sun4i/sun4i_drv.c | 12 +-- drivers/gpu/drm/sun4i/sun4i_framebuffer.c | 12 +-- drivers/gpu/drm/sun4i/sun4i_framebuffer.h | 3 +- drivers/gpu/drm/tilcdc/tilcdc_drv.c | 11 +- include/drm/drm_fb_cma_helper.h | 22 19 files changed, 24 insertions(+), 347 deletions(-) -- 2.15.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 8/9] drm/tilcdc: Use drm_fbdev_generic_setup()
The CMA helper is already using the drm_fb_helper_generic_probe part of
the generic fbdev emulation. This patch makes full use of the generic
fbdev emulation by using its drm_client callbacks. This means that
drm_mode_config_funcs->output_poll_changed and drm_driver->lastclose are
now handled by the emulation code. Additionally fbdev unregister happens
automatically on drm_dev_unregister().
The drm_fbdev_generic_setup() call is put after drm_dev_register() in the
driver. This is done to highlight the fact that fbdev emulation is an
internal client that makes use of the driver, it is not part of the
driver as such. If fbdev setup fails, an error is printed, but the driver
succeeds probing.
Cc: Jyri Sarha
Cc: Tomi Valkeinen
Signed-off-by: Noralf Trønnes
Acked-by: Sam Ravnborg
---
drivers/gpu/drm/tilcdc/tilcdc_drv.c | 11 ++-
1 file changed, 2 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
index 33e533268488..3dac08b24140 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
@@ -140,7 +140,6 @@ static int tilcdc_commit(struct drm_device *dev,
static const struct drm_mode_config_funcs mode_config_funcs = {
.fb_create = tilcdc_fb_create,
- .output_poll_changed = drm_fb_helper_output_poll_changed,
.atomic_check = tilcdc_atomic_check,
.atomic_commit = tilcdc_commit,
};
@@ -191,9 +190,6 @@ static void tilcdc_fini(struct drm_device *dev)
drm_dev_unregister(dev);
drm_kms_helper_poll_fini(dev);
-
- drm_fb_cma_fbdev_fini(dev);
-
drm_irq_uninstall(dev);
drm_mode_config_cleanup(dev);
tilcdc_remove_external_device(dev);
@@ -396,16 +392,14 @@ static int tilcdc_init(struct drm_driver *ddrv, struct
device *dev)
drm_mode_config_reset(ddev);
- ret = drm_fb_cma_fbdev_init(ddev, bpp, 0);
- if (ret)
- goto init_failed;
-
drm_kms_helper_poll_init(ddev);
ret = drm_dev_register(ddev, 0);
if (ret)
goto init_failed;
+ drm_fbdev_generic_setup(ddev, bpp);
+
priv->is_registered = true;
return 0;
@@ -519,7 +513,6 @@ DEFINE_DRM_GEM_CMA_FOPS(fops);
static struct drm_driver tilcdc_driver = {
.driver_features= (DRIVER_HAVE_IRQ | DRIVER_GEM | DRIVER_MODESET |
DRIVER_PRIME | DRIVER_ATOMIC),
- .lastclose = drm_fb_helper_lastclose,
.irq_handler= tilcdc_irq,
.gem_free_object_unlocked = drm_gem_cma_free_object,
.gem_print_info = drm_gem_cma_print_info,
--
2.15.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 6/9] drm/atmel-hlcdc: Use drm_fbdev_generic_setup()
The CMA helper is already using the drm_fb_helper_generic_probe part of
the generic fbdev emulation. This patch makes full use of the generic
fbdev emulation by using its drm_client callbacks. This means that
drm_mode_config_funcs->output_poll_changed and drm_driver->lastclose are
now handled by the emulation code. Additionally fbdev unregister happens
automatically on drm_dev_unregister().
The drm_fbdev_generic_setup() call is put after drm_dev_register() in the
driver. This is done to highlight the fact that fbdev emulation is an
internal client that makes use of the driver, it is not part of the
driver as such. If fbdev setup fails, an error is printed, but the driver
succeeds probing.
Cc: Boris Brezillon
Signed-off-by: Noralf Trønnes
Acked-by: Sam Ravnborg
---
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
index fedbfa333bb0..034a91112098 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
@@ -556,7 +556,6 @@ static int atmel_hlcdc_dc_atomic_commit(struct drm_device
*dev,
static const struct drm_mode_config_funcs mode_config_funcs = {
.fb_create = atmel_hlcdc_fb_create,
- .output_poll_changed = drm_fb_helper_output_poll_changed,
.atomic_check = drm_atomic_helper_check,
.atomic_commit = atmel_hlcdc_dc_atomic_commit,
};
@@ -658,8 +657,6 @@ static int atmel_hlcdc_dc_load(struct drm_device *dev)
platform_set_drvdata(pdev, dev);
- drm_fb_cma_fbdev_init(dev, 24, 0);
-
drm_kms_helper_poll_init(dev);
return 0;
@@ -678,7 +675,6 @@ static void atmel_hlcdc_dc_unload(struct drm_device *dev)
{
struct atmel_hlcdc_dc *dc = dev->dev_private;
- drm_fb_cma_fbdev_fini(dev);
flush_workqueue(dc->wq);
drm_kms_helper_poll_fini(dev);
drm_atomic_helper_shutdown(dev);
@@ -727,7 +723,6 @@ static struct drm_driver atmel_hlcdc_dc_driver = {
.driver_features = DRIVER_HAVE_IRQ | DRIVER_GEM |
DRIVER_MODESET | DRIVER_PRIME |
DRIVER_ATOMIC,
- .lastclose = drm_fb_helper_lastclose,
.irq_handler = atmel_hlcdc_dc_irq_handler,
.irq_preinstall = atmel_hlcdc_dc_irq_uninstall,
.irq_postinstall = atmel_hlcdc_dc_irq_postinstall,
@@ -769,6 +764,8 @@ static int atmel_hlcdc_dc_drm_probe(struct platform_device
*pdev)
if (ret)
goto err_unload;
+ drm_fbdev_generic_setup(ddev, 24);
+
return 0;
err_unload:
--
2.15.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 5/9] drm/rcar-du: Use drm_fbdev_generic_setup()
The CMA helper is already using the drm_fb_helper_generic_probe part of
the generic fbdev emulation. This patch makes full use of the generic
fbdev emulation by using its drm_client callbacks. This means that
drm_mode_config_funcs->output_poll_changed and drm_driver->lastclose are
now handled by the emulation code. Additionally fbdev unregister happens
automatically on drm_dev_unregister().
The drm_fbdev_generic_setup() call is put after drm_dev_register() in the
driver. This is done to highlight the fact that fbdev emulation is an
internal client that makes use of the driver, it is not part of the
driver as such. If fbdev setup fails, an error is printed, but the driver
succeeds probing.
drm_fbdev_generic_setup() handles mode_config.num_connector being zero.
In that case it retries fbdev setup on the next .output_poll_changed.
Cc: Laurent Pinchart
Signed-off-by: Noralf Trønnes
Acked-by: Sam Ravnborg
Reviewed-by: Laurent Pinchart
---
Changes since version 1:
- Rebased on: drm/rcar-du: Convert drm_atomic_helper_suspend/resume()
Laurent, do you want to take this through your tree, or do you want me to
apply it to drm-misc-next?
drivers/gpu/drm/rcar-du/rcar_du_drv.c | 15 ---
drivers/gpu/drm/rcar-du/rcar_du_drv.h | 2 --
drivers/gpu/drm/rcar-du/rcar_du_kms.c | 21 -
3 files changed, 4 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
index 7015974c247a..27bfccd5b136 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
@@ -21,7 +21,9 @@
#include
#include
#include
+#include
#include
+#include
#include "rcar_du_drv.h"
#include "rcar_du_kms.h"
@@ -363,19 +365,11 @@ MODULE_DEVICE_TABLE(of, rcar_du_of_table);
* DRM operations
*/
-static void rcar_du_lastclose(struct drm_device *dev)
-{
- struct rcar_du_device *rcdu = dev->dev_private;
-
- drm_fbdev_cma_restore_mode(rcdu->fbdev);
-}
-
DEFINE_DRM_GEM_CMA_FOPS(rcar_du_fops);
static struct drm_driver rcar_du_driver = {
.driver_features= DRIVER_GEM | DRIVER_MODESET | DRIVER_PRIME
| DRIVER_ATOMIC,
- .lastclose = rcar_du_lastclose,
.gem_free_object_unlocked = drm_gem_cma_free_object,
.gem_vm_ops = _gem_cma_vm_ops,
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
@@ -431,9 +425,6 @@ static int rcar_du_remove(struct platform_device *pdev)
drm_dev_unregister(ddev);
- if (rcdu->fbdev)
- drm_fbdev_cma_fini(rcdu->fbdev);
-
drm_kms_helper_poll_fini(ddev);
drm_mode_config_cleanup(ddev);
@@ -493,6 +484,8 @@ static int rcar_du_probe(struct platform_device *pdev)
DRM_INFO("Device %s probed\n", dev_name(>dev));
+ drm_fbdev_generic_setup(ddev, 32);
+
return 0;
error:
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.h
b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
index 9f5563296c5a..a68da79b424e 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
@@ -20,7 +20,6 @@
struct clk;
struct device;
struct drm_device;
-struct drm_fbdev_cma;
struct rcar_du_device;
#define RCAR_DU_FEATURE_CRTC_IRQ_CLOCK BIT(0) /* Per-CRTC IRQ and clock */
@@ -78,7 +77,6 @@ struct rcar_du_device {
void __iomem *mmio;
struct drm_device *ddev;
- struct drm_fbdev_cma *fbdev;
struct rcar_du_crtc crtcs[RCAR_DU_MAX_CRTCS];
unsigned int num_crtcs;
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
index 4ebd61ecbee1..6562871aa706 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
@@ -255,13 +255,6 @@ rcar_du_fb_create(struct drm_device *dev, struct drm_file
*file_priv,
return drm_gem_fb_create(dev, file_priv, mode_cmd);
}
-static void rcar_du_output_poll_changed(struct drm_device *dev)
-{
- struct rcar_du_device *rcdu = dev->dev_private;
-
- drm_fbdev_cma_hotplug_event(rcdu->fbdev);
-}
-
/*
-
* Atomic Check and Update
*/
@@ -308,7 +301,6 @@ static const struct drm_mode_config_helper_funcs
rcar_du_mode_config_helper = {
static const struct drm_mode_config_funcs rcar_du_mode_config_funcs = {
.fb_create = rcar_du_fb_create,
- .output_poll_changed = rcar_du_output_poll_changed,
.atomic_check = rcar_du_atomic_check,
.atomic_commit = drm_atomic_helper_commit,
};
@@ -543,7 +535,6 @@ int rcar_du_modeset_init(struct rcar_du_device *rcdu)
struct drm_device *dev = rcdu->ddev;
struct drm_encoder *encoder;
- struct drm_fbdev_cma *fbdev;
unsigned int dpad0_sources;
unsigned int num_encoders;
unsigned int num_groups;
@@ -682,17 +673,5 @@ int rcar_du_modeset_init(struct rcar_du_device *rcdu)
