Re: [RFC][PATCH 04/11] drm: Split the display info into static and dynamic parts
On Tue, Feb 27, 2018 at 1:56 PM, Ville Syrjala wrote: > From: Ville Syrjälä > > Currently we have a mix of static and dynamic information stored in > the display info structure. That makes it rather difficult to repopulate > the dynamic parts when a new EDID appears. Let's make life easier by > splitting the structure up into static and dynamic parts. > > The static part will consist of subpixel_order, panel_orientation, > and bus_formats. > > Actually I'm not sure where bus_formats & co. fit in all this. For some > drivers those seem to be static, even though they might fill them out > from .get_modes(). For other drivers this stuff even gets frobbed at > runtime, making it more some kind of a bastard encoder/connector state. > I'll just stick it into the static side so that the behaviour doesn't > change when I start clear out the entire dynamic state with memset(). > > Cc: Keith Packard > Cc: Daniel Vetter > Cc: Hans de Goede > Cc: Shashank Sharma > Cc: Stefan Agner > Cc: Thierry Reding > Cc: Boris Brezillon > Cc: Philipp Zabel > Cc: Laurent Pinchart > Cc: Manfred Schlaegl > Cc: Marek Vasut > Cc: Archit Taneja > Cc: Andrzej Hajda > Cc: Alison Wang > Cc: Eric Anholt > Cc: Linus Walleij > Cc: linux-renesas-...@vger.kernel.org > Cc: Maxime Ripard > Signed-off-by: Ville Syrjälä Acked-by: Linus Walleij Yours, Linus Walleij ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/bridge: sii902x: Fall back to standard modes
On Thu, Mar 01, 2018 at 11:12:15PM +0100, Linus Walleij wrote: > On Thu, Mar 1, 2018 at 10:18 PM, Ville Syrjälä > wrote: > > On Thu, Mar 01, 2018 at 10:02:55PM +0100, Linus Walleij wrote: > >> Hm, hard to get review feedback on this one. > >> > >> It gives me proper video on an ARM Versatile Express utilizing the > >> bridge driver with a plugged in DVI-to-VGA dongle with the new > >> PL111 DRI driver. > >> > >> Liviu? Pawel? > >> > >> Some ACK is fine to know I am doing the right thing :) > > > > Why isn't the probe helper's noedid fallback working? > > Where is that in the call chain? > > The problem I have is that the bridge is there, it gets properly > initialized and used as connector and all. The only problem is > that the DDI I2C portion of it is not working, so no modes are > really added from the struct drm_connector_helper_funcs > .get_modes() callback. The helper is what calls .get_modes(), and it has a noedid fallback for mode count==0. -- Ville Syrjälä Intel OTC ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] rnndb/adreno: Add more PM4 opcodes
Add CP_SECURE_MODE and CP_SET_PSEUDO_REG opcodes needed for A6xx hardware features. Signed-off-by: Sharat Masetty --- rnndb/adreno/adreno_pm4.xml | 5 + 1 file changed, 5 insertions(+) diff --git a/rnndb/adreno/adreno_pm4.xml b/rnndb/adreno/adreno_pm4.xml index 3621f07..c1a82da 100644 --- a/rnndb/adreno/adreno_pm4.xml +++ b/rnndb/adreno/adreno_pm4.xml @@ -288,6 +288,11 @@ xsi:schemaLocation="http://nouveau.freedesktop.org/ rules-ng.xsd"> + + Tells CP the current mode of GPU operation + + Instruct CP to set a few inernal CP registers +
Re: [PATCH v2 06/16] drm/sun4i: Don't process LVDS if TCON doesn't support it
Hi, On Wed, Feb 28, 2018 at 10:43:30PM +0100, Jernej Škrabec wrote: > Dne sreda, 28. februar 2018 ob 08:36:08 CET je Maxime Ripard napisal(a): > > On Tue, Feb 27, 2018 at 11:26:51PM +0100, Jernej Skrabec wrote: > > > TCON checks for LVDS properties even if it doesn't support it. Add a > > > check to skip that part of the code if TCON doesn't support channel 0. > > > > > > Signed-off-by: Jernej Skrabec > > > > I have already sent a similar patch here: > > https://lists.freedesktop.org/archives/dri-devel/2018-February/15.html > > Right. However, check last chunk in my patch. There is no need to call > sun4i_rgb_init() if TCON doesn't support channel 0. It doesn't do anything, > except producing warning. Will you add that this change to your patch and > then > I can remove this patch from next revision? They are orthogonal to me though. Mine fixes the spurious LVDS error messages that you were mentionning in your commit log. Your point here is that we shouldn't need to even register the LVDS and RGB output when there's no channel 0. This is obviously true, but it should be in a separate patch. > BTW, your patch won't apply cleanly, since you didn't base it on latest code > (every TCON variant has at least one entry now). I'll fix it when applying. Maxime -- Maxime Ripard, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 05/16] dt-bindings: display: sun4i-drm: Add compatibles for H3 HDMI pipeline
Add missing compatibles for H3 HDMI pipeline. These compatibles can also be used with H5 SoC. Signed-off-by: Jernej Skrabec --- Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 6 ++ 1 file changed, 6 insertions(+) diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt index b995bfee734a..8bdef4920edc 100644 --- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt +++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt @@ -102,6 +102,7 @@ DWC HDMI PHY Required properties: - compatible: value must be one of: * allwinner,sun8i-a83t-hdmi-phy +* allwinner,sun8i-h3-hdmi-phy - reg: base address and size of memory-mapped region - clocks: phandles to the clocks feeding the HDMI PHY * bus: the HDMI PHY interface clock @@ -110,6 +111,9 @@ Required properties: - resets: phandle to the reset controller driving the PHY - reset-names: must be "phy" +H3 HDMI PHY requires additional clock: + - pll-0: parent of phy clock + TV Encoder -- @@ -275,6 +279,7 @@ Required properties: - compatible: value must be one of: * allwinner,sun8i-a83t-de2-mixer-0 * allwinner,sun8i-a83t-de2-mixer-1 +* allwinner,sun8i-h3-de2-mixer-0 * allwinner,sun8i-v3s-de2-mixer - reg: base address and size of the memory-mapped region. - clocks: phandles to the clocks feeding the mixer @@ -305,6 +310,7 @@ Required properties: * allwinner,sun7i-a20-display-engine * allwinner,sun8i-a33-display-engine * allwinner,sun8i-a83t-display-engine +* allwinner,sun8i-h3-display-engine * allwinner,sun8i-v3s-display-engine - allwinner,pipelines: list of phandle to the display engine -- 2.16.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 02/16] clk: sunxi-ng: h3: h5: Add minimal rate for video PLL
Although user manuals for H3 and H5 SoCs state that minimal rate supported by video PLL is around 30 MHz, it seems that in reality minimal rate is around 192 MHz. Experiments showed that any rate below 96 MHz doesn't produce any video output at all. Even at this frequency, stable output depends on right factors. For example, when N = 4 and M = 1, output is stable and when N = 8 and M = 2, it's not. BSP clock driver suggest that minimum stable frequency is 192 MHz. That would also be in line with A64 SoC, which has similar periphery. Set minimal video PLL rate for H3/H5 to 192 MHz. Signed-off-by: Jernej Skrabec --- drivers/clk/sunxi-ng/ccu-sun8i-h3.c | 23 --- 1 file changed, 12 insertions(+), 11 deletions(-) diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-h3.c b/drivers/clk/sunxi-ng/ccu-sun8i-h3.c index 29bc0566b776..b9f39078c0b2 100644 --- a/drivers/clk/sunxi-ng/ccu-sun8i-h3.c +++ b/drivers/clk/sunxi-ng/ccu-sun8i-h3.c @@ -69,17 +69,18 @@ static SUNXI_CCU_NM_WITH_SDM_GATE_LOCK(pll_audio_base_clk, "pll-audio-base", BIT(28), /* lock */ CLK_SET_RATE_UNGATE); -static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK(pll_video_clk, "pll-video", - "osc24M", 0x0010, - 8, 7, /* N */ - 0, 4, /* M */ - BIT(24),/* frac enable */ - BIT(25),/* frac select */ - 27000, /* frac rate 0 */ - 29700, /* frac rate 1 */ - BIT(31),/* gate */ - BIT(28),/* lock */ - CLK_SET_RATE_UNGATE); +static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK_MIN(pll_video_clk, "pll-video", + "osc24M", 0x0010, + 19200, /* Minimum rate */ + 8, 7, /* N */ + 0, 4, /* M */ + BIT(24),/* frac enable */ + BIT(25),/* frac select */ + 27000, /* frac rate 0 */ + 29700, /* frac rate 1 */ + BIT(31),/* gate */ + BIT(28),/* lock */ + CLK_SET_RATE_UNGATE); static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK(pll_ve_clk, "pll-ve", "osc24M", 0x0018, -- 2.16.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 04/16] clk: sunxi-ng: h3: h5: export CLK_PLL_VIDEO
CLK_PLL_VIDEO needs to be referenced in HDMI DT entry as a possible PHY clock parent. Export it so it can be used later in DT. Signed-off-by: Jernej Skrabec --- drivers/clk/sunxi-ng/ccu-sun8i-h3.h | 4 +++- include/dt-bindings/clock/sun8i-h3-ccu.h | 2 ++ 2 files changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-h3.h b/drivers/clk/sunxi-ng/ccu-sun8i-h3.h index 1b4baea37d81..73d7392c968c 100644 --- a/drivers/clk/sunxi-ng/ccu-sun8i-h3.h +++ b/drivers/clk/sunxi-ng/ccu-sun8i-h3.h @@ -26,7 +26,9 @@ #define CLK_PLL_AUDIO_2X 3 #define CLK_PLL_AUDIO_4X 4 #define CLK_PLL_AUDIO_8X 5 -#define CLK_PLL_VIDEO 6 + +/* PLL_VIDEO is exported */ + #define CLK_PLL_VE 7 #define CLK_PLL_DDR8 diff --git a/include/dt-bindings/clock/sun8i-h3-ccu.h b/include/dt-bindings/clock/sun8i-h3-ccu.h index e139fe5c62ec..c5f7e9a70968 100644 --- a/include/dt-bindings/clock/sun8i-h3-ccu.h +++ b/include/dt-bindings/clock/sun8i-h3-ccu.h @@ -43,6 +43,8 @@ #ifndef _DT_BINDINGS_CLK_SUN8I_H3_H_ #define _DT_BINDINGS_CLK_SUN8I_H3_H_ +#define CLK_PLL_VIDEO 6 + #define CLK_PLL_PERIPH09 #define CLK_CPUX 14 -- 2.16.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 11/16] drm/sun4i: Move and expand DW HDMI PHY register macros
DW HDMI PHY macros are moved to header file and expanded with the registers present on newer SoCs like H3 and H5. Signed-off-by: Jernej Skrabec --- drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h | 131 + drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c | 17 - 2 files changed, 131 insertions(+), 17 deletions(-) diff --git a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h index 1e9eb6072615..49161326ea5a 100644 --- a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h +++ b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h @@ -12,6 +12,137 @@ #include #include +#define SUN8I_HDMI_PHY_DBG_CTRL_REG0x +#define SUN8I_HDMI_PHY_DBG_CTRL_PX_LOCKBIT(0) +#define SUN8I_HDMI_PHY_DBG_CTRL_POL_MASK GENMASK(15, 8) +#define SUN8I_HDMI_PHY_DBG_CTRL_POL_NHSYNC BIT(8) +#define SUN8I_HDMI_PHY_DBG_CTRL_POL_NVSYNC BIT(9) +#define SUN8I_HDMI_PHY_DBG_CTRL_ADDR_MASK GENMASK(23, 16) +#define SUN8I_HDMI_PHY_DBG_CTRL_ADDR(addr) (addr << 16) + +#define SUN8I_HDMI_PHY_REXT_CTRL_REG 0x0004 +#define SUN8I_HDMI_PHY_REXT_CTRL_REXT_EN BIT(31) + +#define SUN8I_HDMI_PHY_READ_EN_REG 0x0010 +#define SUN8I_HDMI_PHY_READ_EN_MAGIC 0x54524545 + +#define SUN8I_HDMI_PHY_UNSCRAMBLE_REG 0x0014 +#define SUN8I_HDMI_PHY_UNSCRAMBLE_MAGIC0x42494E47 + +#define SUN8I_HDMI_PHY_ANA_CFG1_REG0x0020 +#define SUN8I_HDMI_PHY_ANA_CFG1_REG_SWIBIT(31) +#define SUN8I_HDMI_PHY_ANA_CFG1_REG_PWEND BIT(30) +#define SUN8I_HDMI_PHY_ANA_CFG1_REG_PWENC BIT(29) +#define SUN8I_HDMI_PHY_ANA_CFG1_REG_CALSW BIT(28) +#define SUN8I_HDMI_PHY_ANA_CFG1_REG_SVRCAL(x) ((x) << 26) +#define SUN8I_HDMI_PHY_ANA_CFG1_REG_SVBH(x)((x) << 24) +#define SUN8I_HDMI_PHY_ANA_CFG1_AMP_OPTBIT(23) +#define SUN8I_HDMI_PHY_ANA_CFG1_EMP_OPTBIT(22) +#define SUN8I_HDMI_PHY_ANA_CFG1_AMPCK_OPT BIT(21) +#define SUN8I_HDMI_PHY_ANA_CFG1_EMPCK_OPT BIT(20) +#define SUN8I_HDMI_PHY_ANA_CFG1_ENRCAL BIT(19) +#define SUN8I_HDMI_PHY_ANA_CFG1_ENCALOGBIT(18) +#define SUN8I_HDMI_PHY_ANA_CFG1_REG_SCKTMDSBIT(17) +#define SUN8I_HDMI_PHY_ANA_CFG1_TMDSCLK_EN BIT(16) +#define SUN8I_HDMI_PHY_ANA_CFG1_TXEN_MASK GENMASK(15, 12) +#define SUN8I_HDMI_PHY_ANA_CFG1_TXEN_ALL (0xf << 12) +#define SUN8I_HDMI_PHY_ANA_CFG1_BIASEN_TMDSCLK BIT(11) +#define SUN8I_HDMI_PHY_ANA_CFG1_BIASEN_TMDS2 BIT(10) +#define SUN8I_HDMI_PHY_ANA_CFG1_BIASEN_TMDS1 BIT(9) +#define SUN8I_HDMI_PHY_ANA_CFG1_BIASEN_TMDS0 BIT(8) +#define SUN8I_HDMI_PHY_ANA_CFG1_ENP2S_TMDSCLK BIT(7) +#define SUN8I_HDMI_PHY_ANA_CFG1_ENP2S_TMDS2BIT(6) +#define SUN8I_HDMI_PHY_ANA_CFG1_ENP2S_TMDS1BIT(5) +#define SUN8I_HDMI_PHY_ANA_CFG1_ENP2S_TMDS0BIT(4) +#define SUN8I_HDMI_PHY_ANA_CFG1_CKEN BIT(3) +#define SUN8I_HDMI_PHY_ANA_CFG1_LDOEN BIT(2) +#define SUN8I_HDMI_PHY_ANA_CFG1_ENVBS BIT(1) +#define SUN8I_HDMI_PHY_ANA_CFG1_ENBI BIT(0) + +#define SUN8I_HDMI_PHY_ANA_CFG2_REG0x0024 +#define SUN8I_HDMI_PHY_ANA_CFG2_M_EN BIT(31) +#define SUN8I_HDMI_PHY_ANA_CFG2_PLLDBENBIT(30) +#define SUN8I_HDMI_PHY_ANA_CFG2_SENBIT(29) +#define SUN8I_HDMI_PHY_ANA_CFG2_REG_HPDPD BIT(28) +#define SUN8I_HDMI_PHY_ANA_CFG2_REG_HPDEN BIT(27) +#define SUN8I_HDMI_PHY_ANA_CFG2_REG_PLRCK BIT(26) +#define SUN8I_HDMI_PHY_ANA_CFG2_REG_PLR(x) ((x) << 23) +#define SUN8I_HDMI_PHY_ANA_CFG2_REG_DENCK BIT(22) +#define SUN8I_HDMI_PHY_ANA_CFG2_REG_DENBIT(21) +#define SUN8I_HDMI_PHY_ANA_CFG2_REG_CD(x) ((x) << 19) +#define SUN8I_HDMI_PHY_ANA_CFG2_REG_CKSS(x)((x) << 17) +#define SUN8I_HDMI_PHY_ANA_CFG2_REG_BIGSWCKBIT(16) +#define SUN8I_HDMI_PHY_ANA_CFG2_REG_BIGSW BIT(15) +#define SUN8I_HDMI_PHY_ANA_CFG2_REG_CSMPS(x) ((x) << 13) +#define SUN8I_HDMI_PHY_ANA_CFG2_REG_SLV(x) ((x) << 10) +#define SUN8I_HDMI_PHY_ANA_CFG2_REG_BOOSTCK(x) ((x) << 8) +#define SUN8I_HDMI_PHY_ANA_CFG2_REG_BOOST(x) ((x) << 6) +#define SUN8I_HDMI_PHY_ANA_CFG2_REG_RESDI(x) ((x) << 0) + +#define SUN8I_HDMI_PHY_ANA_CFG3_REG0x0028 +#define SUN8I_HDMI_PHY_ANA_CFG3_REG_SLOWCK(x) ((x) << 30) +#define SUN8I_HDMI_PHY_ANA_CFG3_REG_SLOW(x)((x) << 28) +#define SUN8I_HDMI_PHY_ANA_CFG3_REG_WIRE(x)((x) << 18) +#define SUN8I_HDMI_PHY_ANA_CFG3_REG_AMPCK(x) ((x) << 14) +#define SUN8I_HDMI_PHY_ANA_CFG3_REG_EMPCK(x) ((x) << 11) +#define SUN8I_HDMI_PHY_ANA_CFG3_REG_AMP(x) ((x) << 7) +#define SUN8I_HDMI_PHY_ANA_CFG3_REG_EMP(x) ((x) << 4) +#define SUN8I_HDMI_PHY_ANA_CFG3_SDAPD BIT(3) +#define SUN8I_HDMI_PHY_ANA_CFG3_SDAEN BIT(2) +#define SUN8I_HDMI_PHY_ANA_CFG3_SCLPD BIT(1) +#define SUN8I_HDMI_PHY_ANA_CFG3_SCLEN BIT(0) + +#define SUN8I_HDMI_PHY_PLL_CFG1_REG0x002c +#define SUN8I_HDMI_PHY_PLL_CFG1_REG_OD1BIT(31) +#define SUN8I_HDMI_PHY_PLL_CFG1_REG_OD BIT(30) +#define SUN8I_HDMI_PHY_PLL_CFG1_LDO2_EN
[PATCH v3 00/16] Implement H3/H5 HDMI driver
This series implements H3/H5 HDMI driver. It was tested on OrangePi 2 (H3), OrangePi Plus2e (H3) and OrangePi PC2 (H5) with many resolutions and it works well. Code is based on linux-next, next-20180228 tag. Best regards, Jernej Changes in v3: - Removed TCON patch to skip LVDS procesing - Added TCON patch to release exclusive clock lock - Minimal clock rate is now returned immediately in round_rate for NM PLLs Changes in v2: - Fixed build warning on arm64 - Fixed condition in determine_rate function in HDMI PHY clock driver - Added defines for polarity settings in HDMI PHY - Added patch to skip LVDS code path altogether if TCON doesn't support it. - round_rate for NM PLLs now rounds to minimal rate if requested rate is lower. - set_rate for NM PLLs doesn't fail if requested rate is lower than minimal (round_rate is called before which already guarantees that rate is not lower than minimal). Jernej Skrabec (16): clk: sunxi-ng: Add check for minimal rate to NM PLLs clk: sunxi-ng: h3: h5: Add minimal rate for video PLL clk: sunxi-ng: h3: h5: Allow some clocks to set parent rate clk: sunxi-ng: h3: h5: export CLK_PLL_VIDEO dt-bindings: display: sun4i-drm: Add compatibles for H3 HDMI pipeline drm/sun4i: Release exclusive clock lock when disabling TCON drm/sun4i: Add support for H3 display engine drm/sun4i: Add support for H3 mixer 0 drm/sun4i: Fix polarity configuration for DW HDMI PHY drm/sun4i: Add support for variants to DW HDMI PHY drm/sun4i: Move and expand DW HDMI PHY register macros drm/sun4i: Add support for H3 HDMI PHY variant drm/sun4i: Allow building on arm64 ARM: dts: sunxi: h3/h5: Add HDMI pipeline ARM: dts: sun8i: h3: Enable HDMI output on H3 boards ARM64: dts: sun50i: h5: Enable HDMI output on H5 boards .../bindings/display/sunxi/sun4i-drm.txt | 6 + arch/arm/boot/dts/sun8i-h3-bananapi-m2-plus.dts| 25 ++ arch/arm/boot/dts/sun8i-h3-beelink-x2.dts | 25 ++ arch/arm/boot/dts/sun8i-h3-libretech-all-h3-cc.dts | 25 ++ arch/arm/boot/dts/sun8i-h3-nanopi-m1.dts | 25 ++ arch/arm/boot/dts/sun8i-h3-orangepi-2.dts | 25 ++ arch/arm/boot/dts/sun8i-h3-orangepi-lite.dts | 25 ++ arch/arm/boot/dts/sun8i-h3-orangepi-one.dts| 24 ++ arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts | 25 ++ arch/arm/boot/dts/sunxi-h3-h5.dtsi | 108 ++ .../boot/dts/allwinner/sun50i-h5-orangepi-pc2.dts | 25 ++ .../dts/allwinner/sun50i-h5-orangepi-prime.dts | 25 ++ .../allwinner/sun50i-h5-orangepi-zero-plus2.dts| 25 ++ drivers/clk/sunxi-ng/ccu-sun8i-h3.c| 32 +- drivers/clk/sunxi-ng/ccu-sun8i-h3.h| 4 +- drivers/clk/sunxi-ng/ccu_nm.c | 7 + drivers/clk/sunxi-ng/ccu_nm.h | 27 ++ drivers/gpu/drm/sun4i/Kconfig | 2 +- drivers/gpu/drm/sun4i/Makefile | 1 + drivers/gpu/drm/sun4i/sun4i_drv.c | 1 + drivers/gpu/drm/sun4i/sun4i_tcon.c | 6 +- drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h | 157 - drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c | 369 ++--- drivers/gpu/drm/sun4i/sun8i_hdmi_phy_clk.c | 132 drivers/gpu/drm/sun4i/sun8i_mixer.c| 12 + include/dt-bindings/clock/sun8i-h3-ccu.h | 2 + 26 files changed, 1070 insertions(+), 70 deletions(-) create mode 100644 drivers/gpu/drm/sun4i/sun8i_hdmi_phy_clk.c -- 2.16.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 01/16] clk: sunxi-ng: Add check for minimal rate to NM PLLs
Some NM PLLs doesn't work well when their output clock rate is set below
certain rate.
Add support for that constrain.
Signed-off-by: Jernej Skrabec
---
drivers/clk/sunxi-ng/ccu_nm.c | 7 +++
drivers/clk/sunxi-ng/ccu_nm.h | 27 +++
2 files changed, 34 insertions(+)
diff --git a/drivers/clk/sunxi-ng/ccu_nm.c b/drivers/clk/sunxi-ng/ccu_nm.c
index a16de092bf94..4e2073307f34 100644
--- a/drivers/clk/sunxi-ng/ccu_nm.c
+++ b/drivers/clk/sunxi-ng/ccu_nm.c
@@ -117,6 +117,13 @@ static long ccu_nm_round_rate(struct clk_hw *hw, unsigned
long rate,
if (nm->common.features & CCU_FEATURE_FIXED_POSTDIV)
rate *= nm->fixed_post_div;
+ if (rate < nm->min_rate) {
+ rate = nm->min_rate;
+ if (nm->common.features & CCU_FEATURE_FIXED_POSTDIV)
+ rate /= nm->fixed_post_div;
+ return rate;
+ }
+
if (ccu_frac_helper_has_rate(&nm->common, &nm->frac, rate)) {
if (nm->common.features & CCU_FEATURE_FIXED_POSTDIV)
rate /= nm->fixed_post_div;
diff --git a/drivers/clk/sunxi-ng/ccu_nm.h b/drivers/clk/sunxi-ng/ccu_nm.h
index eba586b4c7d0..1d8b459c50b7 100644
--- a/drivers/clk/sunxi-ng/ccu_nm.h
+++ b/drivers/clk/sunxi-ng/ccu_nm.h
@@ -37,6 +37,7 @@ struct ccu_nm {
struct ccu_sdm_internal sdm;
unsigned intfixed_post_div;
+ unsigned intmin_rate;
struct ccu_common common;
};
@@ -88,6 +89,32 @@ struct ccu_nm {
}, \
}
+#define SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK_MIN(_struct, _name, _parent, \
+_reg, _min_rate, \
+_nshift, _nwidth, \
+_mshift, _mwidth, \
+_frac_en, _frac_sel, \
+_frac_rate_0, _frac_rate_1,\
+_gate, _lock, _flags) \
+ struct ccu_nm _struct = { \
+ .enable = _gate,\
+ .lock = _lock,\
+ .n = _SUNXI_CCU_MULT(_nshift, _nwidth),\
+ .m = _SUNXI_CCU_DIV(_mshift, _mwidth), \
+ .frac = _SUNXI_CCU_FRAC(_frac_en, _frac_sel, \
+ _frac_rate_0, \
+ _frac_rate_1),\
+ .min_rate = _min_rate,\
+ .common = { \
+ .reg= _reg, \
+ .features = CCU_FEATURE_FRACTIONAL, \
+ .hw.init= CLK_HW_INIT(_name,\
+ _parent, \
+ &ccu_nm_ops, \
+ _flags), \
+ }, \
+ }
+
#define SUNXI_CCU_NM_WITH_GATE_LOCK(_struct, _name, _parent, _reg, \
_nshift, _nwidth, \
_mshift, _mwidth, \
--
2.16.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 16/16] ARM64: dts: sun50i: h5: Enable HDMI output on H5 boards
Enable HDMI output on all boards with HDMI connector.
Signed-off-by: Jernej Skrabec
---
.../boot/dts/allwinner/sun50i-h5-orangepi-pc2.dts | 25 ++
.../dts/allwinner/sun50i-h5-orangepi-prime.dts | 25 ++
.../allwinner/sun50i-h5-orangepi-zero-plus2.dts| 25 ++
3 files changed, 75 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-pc2.dts
b/arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-pc2.dts
index 58505fbc2667..98862c7c7258 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-pc2.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-pc2.dts
@@ -67,6 +67,17 @@
stdout-path = "serial0:115200n8";
};
+ connector {
+ compatible = "hdmi-connector";
+ type = "a";
+
+ port {
+ hdmi_con_in: endpoint {
+ remote-endpoint = <&hdmi_out_con>;
+ };
+ };
+ };
+
leds {
compatible = "gpio-leds";
@@ -121,6 +132,10 @@
status = "okay";
};
+&de {
+ status = "okay";
+};
+
&ehci0 {
status = "okay";
};
@@ -153,6 +168,16 @@
};
};
+&hdmi {
+ status = "okay";
+};
+
+&hdmi_out {
+ hdmi_out_con: endpoint {
+ remote-endpoint = <&hdmi_con_in>;
+ };
+};
+
&ir {
pinctrl-names = "default";
pinctrl-0 = <&ir_pins_a>;
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-prime.dts
b/arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-prime.dts
index 803566608ed8..b75ca4d7d001 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-prime.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-prime.dts
@@ -62,6 +62,17 @@
stdout-path = "serial0:115200n8";
};
+ connector {
+ compatible = "hdmi-connector";
+ type = "a";
+
+ port {
+ hdmi_con_in: endpoint {
+ remote-endpoint = <&hdmi_out_con>;
+ };
+ };
+ };
+
leds {
compatible = "gpio-leds";
@@ -128,6 +139,10 @@
status = "okay";
};
+&de {
+ status = "okay";
+};
+
&ehci0 {
status = "okay";
};
@@ -160,6 +175,16 @@
};
};
+&hdmi {
+ status = "okay";
+};
+
+&hdmi_out {
+ hdmi_out_con: endpoint {
+ remote-endpoint = <&hdmi_con_in>;
+ };
+};
+
&ir {
pinctrl-names = "default";
pinctrl-0 = <&ir_pins_a>;
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-zero-plus2.dts
b/arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-zero-plus2.dts
index eda24d813282..53c8c11620e0 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-zero-plus2.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-zero-plus2.dts
@@ -58,6 +58,17 @@
stdout-path = "serial0:115200n8";
};
+ connector {
+ compatible = "hdmi-connector";
+ type = "a";
+
+ port {
+ hdmi_con_in: endpoint {
+ remote-endpoint = <&hdmi_out_con>;
+ };
+ };
+ };
+
reg_vcc3v3: vcc3v3 {
compatible = "regulator-fixed";
regulator-name = "vcc3v3";
@@ -73,6 +84,20 @@
};
};
+&de {
+ status = "okay";
+};
+
+&hdmi {
+ status = "okay";
+};
+
+&hdmi_out {
+ hdmi_out_con: endpoint {
+ remote-endpoint = <&hdmi_con_in>;
+ };
+};
+
&mmc0 {
vmmc-supply = <®_vcc3v3>;
bus-width = <4>;
--
2.16.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 10/16] drm/sun4i: Add support for variants to DW HDMI PHY
There are multiple variants of DW HDMI PHYs in Allwinner SoCs. While
some things like clock and reset setup are the same, PHY configuration
differs a lot.
Split out code which is PHY specific to separate functions and create
a structure which holds pointers to those functions.
Signed-off-by: Jernej Skrabec
---
drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h | 20 ++--
drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c | 89 +++---
2 files changed, 76 insertions(+), 33 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
index d8d0684fc8aa..1e9eb6072615 100644
--- a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
+++ b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
@@ -12,11 +12,23 @@
#include
#include
+struct sun8i_hdmi_phy;
+
+struct sun8i_hdmi_phy_variant {
+ void (*phy_init)(struct sun8i_hdmi_phy *phy);
+ void (*phy_disable)(struct dw_hdmi *hdmi,
+ struct sun8i_hdmi_phy *phy);
+ int (*phy_config)(struct dw_hdmi *hdmi,
+ struct sun8i_hdmi_phy *phy,
+ unsigned int clk_rate);
+};
+
struct sun8i_hdmi_phy {
- struct clk *clk_bus;
- struct clk *clk_mod;
- struct regmap *regs;
- struct reset_control*rst_phy;
+ struct clk *clk_bus;
+ struct clk *clk_mod;
+ struct regmap *regs;
+ struct reset_control*rst_phy;
+ struct sun8i_hdmi_phy_variant *variant;
};
struct sun8i_dw_hdmi {
diff --git a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
index 9d2f11ca3538..17aada64bafd 100644
--- a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
+++ b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
@@ -30,21 +30,10 @@
*/
#define I2C_ADDR 0x69
-static int sun8i_hdmi_phy_config(struct dw_hdmi *hdmi, void *data,
-struct drm_display_mode *mode)
+static int sun8i_hdmi_phy_config_a83t(struct dw_hdmi *hdmi,
+ struct sun8i_hdmi_phy *phy,
+ unsigned int clk_rate)
{
- struct sun8i_hdmi_phy *phy = (struct sun8i_hdmi_phy *)data;
- u32 val = 0;
-
- if (mode->flags & DRM_MODE_FLAG_NHSYNC)
- val |= SUN8I_HDMI_PHY_DBG_CTRL_POL_NHSYNC;
-
- if (mode->flags & DRM_MODE_FLAG_NVSYNC)
- val |= SUN8I_HDMI_PHY_DBG_CTRL_POL_NVSYNC;
-
- regmap_update_bits(phy->regs, SUN8I_HDMI_PHY_DBG_CTRL_REG,
- SUN8I_HDMI_PHY_DBG_CTRL_POL_MASK, val);
-
regmap_update_bits(phy->regs, SUN8I_HDMI_PHY_REXT_CTRL_REG,
SUN8I_HDMI_PHY_REXT_CTRL_REXT_EN,
SUN8I_HDMI_PHY_REXT_CTRL_REXT_EN);
@@ -64,21 +53,21 @@ static int sun8i_hdmi_phy_config(struct dw_hdmi *hdmi, void
*data,
* release any documentation, explanation of this values can
* be found in i.MX 6Dual/6Quad Reference Manual.
*/
- if (mode->crtc_clock <= 27000) {
+ if (clk_rate <= 2700) {
dw_hdmi_phy_i2c_write(hdmi, 0x01e0, 0x06);
dw_hdmi_phy_i2c_write(hdmi, 0x, 0x15);
dw_hdmi_phy_i2c_write(hdmi, 0x08da, 0x10);
dw_hdmi_phy_i2c_write(hdmi, 0x0007, 0x19);
dw_hdmi_phy_i2c_write(hdmi, 0x0318, 0x0e);
dw_hdmi_phy_i2c_write(hdmi, 0x8009, 0x09);
- } else if (mode->crtc_clock <= 74250) {
+ } else if (clk_rate <= 7425) {
dw_hdmi_phy_i2c_write(hdmi, 0x0540, 0x06);
dw_hdmi_phy_i2c_write(hdmi, 0x0005, 0x15);
dw_hdmi_phy_i2c_write(hdmi, 0x, 0x10);
dw_hdmi_phy_i2c_write(hdmi, 0x0007, 0x19);
dw_hdmi_phy_i2c_write(hdmi, 0x02b5, 0x0e);
dw_hdmi_phy_i2c_write(hdmi, 0x8009, 0x09);
- } else if (mode->crtc_clock <= 148500) {
+ } else if (clk_rate <= 14850) {
dw_hdmi_phy_i2c_write(hdmi, 0x04a0, 0x06);
dw_hdmi_phy_i2c_write(hdmi, 0x000a, 0x15);
dw_hdmi_phy_i2c_write(hdmi, 0x, 0x10);
@@ -103,10 +92,27 @@ static int sun8i_hdmi_phy_config(struct dw_hdmi *hdmi,
void *data,
return 0;
};
-static void sun8i_hdmi_phy_disable(struct dw_hdmi *hdmi, void *data)
+static int sun8i_hdmi_phy_config(struct dw_hdmi *hdmi, void *data,
+struct drm_display_mode *mode)
{
struct sun8i_hdmi_phy *phy = (struct sun8i_hdmi_phy *)data;
+ u32 val = 0;
+
+ if (mode->flags & DRM_MODE_FLAG_NHSYNC)
+ val |= SUN8I_HDMI_PHY_DBG_CTRL_POL_NHSYNC;
+ if (mode->flags & DRM_MODE_FLAG_NVSYNC)
+ val |= SUN8I_HDMI_PHY_DBG_CTRL_POL_NVSYNC;
+
+ regmap_update_bits(phy->regs, SUN8I_HDMI_PHY_DBG_CTRL_REG,
+ SUN8I_HDMI_PHY_DBG_CTRL_POL_MASK, val);
+
+ re
[PATCH v3 09/16] drm/sun4i: Fix polarity configuration for DW HDMI PHY
Current polarity configuration code is cleary wrong since it compares
same flag two times. However, even if flag name is fixed, it won't work
well for resolutions which have one polarity positive and another
negative.
Fix that by properly set each bit according to each polarity. Since
those two bits are not described in any documentation, relationships
were obtained by experimentation.
Fixes: b7c7436a5ff0 ("drm/sun4i: Implement A83T HDMI driver")
Signed-off-by: Jernej Skrabec
---
drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
index e5bfcdd43ec9..9d2f11ca3538 100644
--- a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
+++ b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
@@ -10,7 +10,8 @@
#define SUN8I_HDMI_PHY_DBG_CTRL_REG0x
#define SUN8I_HDMI_PHY_DBG_CTRL_PX_LOCKBIT(0)
#define SUN8I_HDMI_PHY_DBG_CTRL_POL_MASK GENMASK(15, 8)
-#define SUN8I_HDMI_PHY_DBG_CTRL_POL(val) (val << 8)
+#define SUN8I_HDMI_PHY_DBG_CTRL_POL_NHSYNC BIT(8)
+#define SUN8I_HDMI_PHY_DBG_CTRL_POL_NVSYNC BIT(9)
#define SUN8I_HDMI_PHY_DBG_CTRL_ADDR_MASK GENMASK(23, 16)
#define SUN8I_HDMI_PHY_DBG_CTRL_ADDR(addr) (addr << 16)
@@ -35,14 +36,14 @@ static int sun8i_hdmi_phy_config(struct dw_hdmi *hdmi, void
*data,
struct sun8i_hdmi_phy *phy = (struct sun8i_hdmi_phy *)data;
u32 val = 0;
- if ((mode->flags & DRM_MODE_FLAG_NHSYNC) &&
- (mode->flags & DRM_MODE_FLAG_NHSYNC)) {
- val = 0x03;
- }
+ if (mode->flags & DRM_MODE_FLAG_NHSYNC)
+ val |= SUN8I_HDMI_PHY_DBG_CTRL_POL_NHSYNC;
+
+ if (mode->flags & DRM_MODE_FLAG_NVSYNC)
+ val |= SUN8I_HDMI_PHY_DBG_CTRL_POL_NVSYNC;
regmap_update_bits(phy->regs, SUN8I_HDMI_PHY_DBG_CTRL_REG,
- SUN8I_HDMI_PHY_DBG_CTRL_POL_MASK,
- SUN8I_HDMI_PHY_DBG_CTRL_POL(val));
+ SUN8I_HDMI_PHY_DBG_CTRL_POL_MASK, val);
regmap_update_bits(phy->regs, SUN8I_HDMI_PHY_REXT_CTRL_REG,
SUN8I_HDMI_PHY_REXT_CTRL_REXT_EN,
--
2.16.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 13/16] drm/sun4i: Allow building on arm64
64-bit ARM SoCs from Allwinner have DE2/TCON/HDMI periphery which is compatible to 32-bit SoCs, so allow building DRM driver for arm64 architecture. Signed-off-by: Jernej Skrabec --- drivers/gpu/drm/sun4i/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/sun4i/Kconfig b/drivers/gpu/drm/sun4i/Kconfig index 7327da3bc94f..eee6bc0eaf97 100644 --- a/drivers/gpu/drm/sun4i/Kconfig +++ b/drivers/gpu/drm/sun4i/Kconfig @@ -1,6 +1,6 @@ config DRM_SUN4I tristate "DRM Support for Allwinner A10 Display Engine" - depends on DRM && ARM && COMMON_CLK + depends on DRM && (ARM || ARM64) && COMMON_CLK depends on ARCH_SUNXI || COMPILE_TEST select DRM_GEM_CMA_HELPER select DRM_KMS_HELPER -- 2.16.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 07/16] drm/sun4i: Add support for H3 display engine
H3 display engine has two mixers which are connected to HDMI and TV
output.
Signed-off-by: Jernej Skrabec
---
drivers/gpu/drm/sun4i/sun4i_drv.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c
b/drivers/gpu/drm/sun4i/sun4i_drv.c
index 3957c2ff6870..a0f43b81c64c 100644
--- a/drivers/gpu/drm/sun4i/sun4i_drv.c
+++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
@@ -359,6 +359,7 @@ static const struct of_device_id sun4i_drv_of_table[] = {
{ .compatible = "allwinner,sun7i-a20-display-engine" },
{ .compatible = "allwinner,sun8i-a33-display-engine" },
{ .compatible = "allwinner,sun8i-a83t-display-engine" },
+ { .compatible = "allwinner,sun8i-h3-display-engine" },
{ .compatible = "allwinner,sun8i-v3s-display-engine" },
{ }
};
--
2.16.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 15/16] ARM: dts: sun8i: h3: Enable HDMI output on H3 boards
Enable HDMI output on all boards which have HDMI connector.
Signed-off-by: Jernej Skrabec
---
arch/arm/boot/dts/sun8i-h3-bananapi-m2-plus.dts| 25 ++
arch/arm/boot/dts/sun8i-h3-beelink-x2.dts | 25 ++
arch/arm/boot/dts/sun8i-h3-libretech-all-h3-cc.dts | 25 ++
arch/arm/boot/dts/sun8i-h3-nanopi-m1.dts | 25 ++
arch/arm/boot/dts/sun8i-h3-orangepi-2.dts | 25 ++
arch/arm/boot/dts/sun8i-h3-orangepi-lite.dts | 25 ++
arch/arm/boot/dts/sun8i-h3-orangepi-one.dts| 24 +
arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts | 25 ++
8 files changed, 199 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-h3-bananapi-m2-plus.dts
b/arch/arm/boot/dts/sun8i-h3-bananapi-m2-plus.dts
index 9c1bc472fb1c..30540dc8e0c5 100644
--- a/arch/arm/boot/dts/sun8i-h3-bananapi-m2-plus.dts
+++ b/arch/arm/boot/dts/sun8i-h3-bananapi-m2-plus.dts
@@ -61,6 +61,17 @@
stdout-path = "serial0:115200n8";
};
+ connector {
+ compatible = "hdmi-connector";
+ type = "a";
+
+ port {
+ hdmi_con_in: endpoint {
+ remote-endpoint = <&hdmi_out_con>;
+ };
+ };
+ };
+
leds {
compatible = "gpio-leds";
pinctrl-names = "default";
@@ -100,6 +111,10 @@
};
};
+&de {
+ status = "okay";
+};
+
&ehci0 {
status = "okay";
};
@@ -129,6 +144,16 @@
};
};
+&hdmi {
+ status = "okay";
+};
+
+&hdmi_out {
+ hdmi_out_con: endpoint {
+ remote-endpoint = <&hdmi_con_in>;
+ };
+};
+
&ir {
pinctrl-names = "default";
pinctrl-0 = <&ir_pins_a>;
diff --git a/arch/arm/boot/dts/sun8i-h3-beelink-x2.dts
b/arch/arm/boot/dts/sun8i-h3-beelink-x2.dts
index 870aabcbb2d8..cf1f970b0c6f 100644
--- a/arch/arm/boot/dts/sun8i-h3-beelink-x2.dts
+++ b/arch/arm/boot/dts/sun8i-h3-beelink-x2.dts
@@ -61,6 +61,17 @@
stdout-path = "serial0:115200n8";
};
+ connector {
+ compatible = "hdmi-connector";
+ type = "a";
+
+ port {
+ hdmi_con_in: endpoint {
+ remote-endpoint = <&hdmi_out_con>;
+ };
+ };
+ };
+
leds {
compatible = "gpio-leds";
@@ -100,6 +111,10 @@
};
};
+&de {
+ status = "okay";
+};
+
&ehci0 {
status = "okay";
};
@@ -108,6 +123,16 @@
status = "okay";
};
+&hdmi {
+ status = "okay";
+};
+
+&hdmi_out {
+ hdmi_out_con: endpoint {
+ remote-endpoint = <&hdmi_con_in>;
+ };
+};
+
&ir {
pinctrl-names = "default";
pinctrl-0 = <&ir_pins_a>;
diff --git a/arch/arm/boot/dts/sun8i-h3-libretech-all-h3-cc.dts
b/arch/arm/boot/dts/sun8i-h3-libretech-all-h3-cc.dts
index d0d41eb86cb4..b20a710da7bc 100644
--- a/arch/arm/boot/dts/sun8i-h3-libretech-all-h3-cc.dts
+++ b/arch/arm/boot/dts/sun8i-h3-libretech-all-h3-cc.dts
@@ -23,6 +23,17 @@
stdout-path = "serial0:115200n8";
};
+ connector {
+ compatible = "hdmi-connector";
+ type = "a";
+
+ port {
+ hdmi_con_in: endpoint {
+ remote-endpoint = <&hdmi_out_con>;
+ };
+ };
+ };
+
leds {
compatible = "gpio-leds";
@@ -120,6 +131,10 @@
status = "okay";
};
+&de {
+ status = "okay";
+};
+
&ehci0 {
status = "okay";
};
@@ -143,6 +158,16 @@
status = "okay";
};
+&hdmi {
+ status = "okay";
+};
+
+&hdmi_out {
+ hdmi_out_con: endpoint {
+ remote-endpoint = <&hdmi_con_in>;
+ };
+};
+
&ir {
pinctrl-names = "default";
pinctrl-0 = <&ir_pins_a>;
diff --git a/arch/arm/boot/dts/sun8i-h3-nanopi-m1.dts
b/arch/arm/boot/dts/sun8i-h3-nanopi-m1.dts
index c77fbca4f227..9412668bb888 100644
--- a/arch/arm/boot/dts/sun8i-h3-nanopi-m1.dts
+++ b/arch/arm/boot/dts/sun8i-h3-nanopi-m1.dts
@@ -49,6 +49,21 @@
aliases {
ethernet0 = &emac;
};
+
+ connector {
+ compatible = "hdmi-connector";
+ type = "a";
+
+ port {
+ hdmi_con_in: endpoint {
+ remote-endpoint = <&hdmi_out_con>;
+ };
+ };
+ };
+};
+
+&de {
+ status = "okay";
};
&ehci1 {
@@ -66,6 +81,16 @@
status = "okay";
};
+&hdmi {
+ status = "okay";
+};
+
+&hdmi_out {
+ hdmi_out_con: endpoint {
+ remote-endpoint = <&hdmi_con_in>;
+ };
+};
+
&ir {
pinctrl-names = "default";
pinctrl-0
[PATCH v3 08/16] drm/sun4i: Add support for H3 mixer 0
This mixer supports 1 VI plane, 3 UI plane and HW scaling on all planes.
Signed-off-by: Jernej Skrabec
---
drivers/gpu/drm/sun4i/sun8i_mixer.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.c
b/drivers/gpu/drm/sun4i/sun8i_mixer.c
index 9b0256d31a61..126899d6f0d3 100644
--- a/drivers/gpu/drm/sun4i/sun8i_mixer.c
+++ b/drivers/gpu/drm/sun4i/sun8i_mixer.c
@@ -492,6 +492,14 @@ static const struct sun8i_mixer_cfg sun8i_a83t_mixer1_cfg
= {
.vi_num = 1,
};
+static const struct sun8i_mixer_cfg sun8i_h3_mixer0_cfg = {
+ .ccsc = 0,
+ .mod_rate = 43200,
+ .scaler_mask= 0xf,
+ .ui_num = 3,
+ .vi_num = 1,
+};
+
static const struct sun8i_mixer_cfg sun8i_v3s_mixer_cfg = {
.vi_num = 2,
.ui_num = 1,
@@ -509,6 +517,10 @@ static const struct of_device_id sun8i_mixer_of_table[] = {
.compatible = "allwinner,sun8i-a83t-de2-mixer-1",
.data = &sun8i_a83t_mixer1_cfg,
},
+ {
+ .compatible = "allwinner,sun8i-h3-de2-mixer-0",
+ .data = &sun8i_h3_mixer0_cfg,
+ },
{
.compatible = "allwinner,sun8i-v3s-de2-mixer",
.data = &sun8i_v3s_mixer_cfg,
--
2.16.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 14/16] ARM: dts: sunxi: h3/h5: Add HDMI pipeline
This commit adds all entries needed for HDMI to function properly.
Signed-off-by: Jernej Skrabec
---
arch/arm/boot/dts/sunxi-h3-h5.dtsi | 108 +
1 file changed, 108 insertions(+)
diff --git a/arch/arm/boot/dts/sunxi-h3-h5.dtsi
b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
index 7741166d34d8..1be1a02d6df2 100644
--- a/arch/arm/boot/dts/sunxi-h3-h5.dtsi
+++ b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
@@ -105,6 +105,12 @@
};
};
+ de: display-engine {
+ compatible = "allwinner,sun8i-h3-display-engine";
+ allwinner,pipelines = <&mixer0>;
+ status = "disabled";
+ };
+
soc {
compatible = "simple-bus";
#address-cells = <1>;
@@ -123,6 +129,29 @@
#reset-cells = <1>;
};
+ mixer0: mixer@110 {
+ compatible = "allwinner,sun8i-h3-de2-mixer-0";
+ reg = <0x0110 0x10>;
+ clocks = <&display_clocks CLK_BUS_MIXER0>,
+<&display_clocks CLK_MIXER0>;
+ clock-names = "bus",
+ "mod";
+ resets = <&display_clocks RST_MIXER0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ mixer0_out: port@1 {
+ reg = <1>;
+
+ mixer0_out_tcon0: endpoint {
+ remote-endpoint =
<&tcon0_in_mixer0>;
+ };
+ };
+ };
+ };
+
syscon: syscon@1c0 {
compatible = "allwinner,sun8i-h3-system-controller",
"syscon";
@@ -138,6 +167,41 @@
#dma-cells = <1>;
};
+ tcon0: lcd-controller@1c0c000 {
+ compatible = "allwinner,sun8i-h3-tcon-tv",
+"allwinner,sun8i-a83t-tcon-tv";
+ reg = <0x01c0c000 0x1000>;
+ interrupts = ;
+ clocks = <&ccu CLK_BUS_TCON0>, <&ccu CLK_TCON0>;
+ clock-names = "ahb", "tcon-ch1";
+ resets = <&ccu RST_BUS_TCON0>;
+ reset-names = "lcd";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ tcon0_in: port@0 {
+ reg = <0>;
+
+ tcon0_in_mixer0: endpoint {
+ remote-endpoint =
<&mixer0_out_tcon0>;
+ };
+ };
+
+ tcon0_out: port@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+
+ tcon0_out_hdmi: endpoint@1 {
+ reg = <1>;
+ remote-endpoint =
<&hdmi_in_tcon0>;
+ };
+ };
+ };
+ };
+
mmc0: mmc@1c0f000 {
/* compatible and clocks are in per SoC .dtsi file */
reg = <0x01c0f000 0x1000>;
@@ -682,6 +746,50 @@
interrupts = ;
};
+ hdmi: hdmi@1ee {
+ compatible = "allwinner,sun8i-h3-dw-hdmi",
+"allwinner,sun8i-a83t-dw-hdmi";
+ reg = <0x01ee 0x1>;
+ reg-io-width = <1>;
+ interrupts = ;
+ clocks = <&ccu CLK_BUS_HDMI>, <&ccu CLK_HDMI_DDC>,
+<&ccu CLK_HDMI>;
+ clock-names = "iahb", "isfr", "tmds";
+ resets = <&ccu RST_BUS_HDMI1>;
+ reset-names = "ctrl";
+ phys = <&hdmi_phy>;
+ phy-names = "hdmi-phy";
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ hdmi_in: port@0 {
+ reg = <0>;
+
+ hdmi_in_tcon0: endpoint {
+ remote-endpoint =
<&tcon0_out_hdmi>;
Re: [PATCH] drm/radeon/mkregtable: Delete unused list functions and macros
On Wed, Feb 28, 2018 at 2:17 PM, Matthias Kaehlcke wrote:
> The util mkregtable includes a copy of the kernel API for linked lists,
> only a small subset of it is used. Delete the unused functions and macros.
>
> Signed-off-by: Matthias Kaehlcke
Reviewed-by: Guenter Roeck
> ---
> drivers/gpu/drm/radeon/mkregtable.c | 433
> 1 file changed, 433 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/mkregtable.c
> b/drivers/gpu/drm/radeon/mkregtable.c
> index c21d8fa591ef..ba704633b072 100644
> --- a/drivers/gpu/drm/radeon/mkregtable.c
> +++ b/drivers/gpu/drm/radeon/mkregtable.c
> @@ -43,10 +43,6 @@ struct list_head {
> struct list_head *next, *prev;
> };
>
> -#define LIST_HEAD_INIT(name) { &(name), &(name) }
> -
> -#define LIST_HEAD(name) \
> - struct list_head name = LIST_HEAD_INIT(name)
>
> static inline void INIT_LIST_HEAD(struct list_head *list)
> {
> @@ -74,19 +70,6 @@ extern void __list_add(struct list_head *new,
>struct list_head *prev, struct list_head *next);
> #endif
>
> -/**
> - * list_add - add a new entry
> - * @new: new entry to be added
> - * @head: list head to add it after
> - *
> - * Insert a new entry after the specified head.
> - * This is good for implementing stacks.
> - */
> -static inline void list_add(struct list_head *new, struct list_head *head)
> -{
> - __list_add(new, head, head->next);
> -}
> -
> /**
> * list_add_tail - add a new entry
> * @new: new entry to be added
> @@ -100,250 +83,6 @@ static inline void list_add_tail(struct list_head *new,
> struct list_head *head)
> __list_add(new, head->prev, head);
> }
>
> -/*
> - * Delete a list entry by making the prev/next entries
> - * point to each other.
> - *
> - * This is only for internal list manipulation where we know
> - * the prev/next entries already!
> - */
> -static inline void __list_del(struct list_head *prev, struct list_head *next)
> -{
> - next->prev = prev;
> - prev->next = next;
> -}
> -
> -/**
> - * list_del - deletes entry from list.
> - * @entry: the element to delete from the list.
> - * Note: list_empty() on entry does not return true after this, the entry is
> - * in an undefined state.
> - */
> -#ifndef CONFIG_DEBUG_LIST
> -static inline void list_del(struct list_head *entry)
> -{
> - __list_del(entry->prev, entry->next);
> - entry->next = (void *)0xDEADBEEF;
> - entry->prev = (void *)0xBEEFDEAD;
> -}
> -#else
> -extern void list_del(struct list_head *entry);
> -#endif
> -
> -/**
> - * list_replace - replace old entry by new one
> - * @old : the element to be replaced
> - * @new : the new element to insert
> - *
> - * If @old was empty, it will be overwritten.
> - */
> -static inline void list_replace(struct list_head *old, struct list_head *new)
> -{
> - new->next = old->next;
> - new->next->prev = new;
> - new->prev = old->prev;
> - new->prev->next = new;
> -}
> -
> -static inline void list_replace_init(struct list_head *old,
> -struct list_head *new)
> -{
> - list_replace(old, new);
> - INIT_LIST_HEAD(old);
> -}
> -
> -/**
> - * list_del_init - deletes entry from list and reinitialize it.
> - * @entry: the element to delete from the list.
> - */
> -static inline void list_del_init(struct list_head *entry)
> -{
> - __list_del(entry->prev, entry->next);
> - INIT_LIST_HEAD(entry);
> -}
> -
> -/**
> - * list_move - delete from one list and add as another's head
> - * @list: the entry to move
> - * @head: the head that will precede our entry
> - */
> -static inline void list_move(struct list_head *list, struct list_head *head)
> -{
> - __list_del(list->prev, list->next);
> - list_add(list, head);
> -}
> -
> -/**
> - * list_move_tail - delete from one list and add as another's tail
> - * @list: the entry to move
> - * @head: the head that will follow our entry
> - */
> -static inline void list_move_tail(struct list_head *list,
> - struct list_head *head)
> -{
> - __list_del(list->prev, list->next);
> - list_add_tail(list, head);
> -}
> -
> -/**
> - * list_is_last - tests whether @list is the last entry in list @head
> - * @list: the entry to test
> - * @head: the head of the list
> - */
> -static inline int list_is_last(const struct list_head *list,
> - const struct list_head *head)
> -{
> - return list->next == head;
> -}
> -
> -/**
> - * list_empty - tests whether a list is empty
> - * @head: the list to test.
> - */
> -static inline int list_empty(const struct list_head *head)
> -{
> - return head->next == head;
> -}
> -
> -/**
> - * list_empty_careful - tests whether a list is empty and not being modified
> - * @head: the list to test
> - *
> - * Description:
> - * tests whether a list is empty _and_ checks that no other CPU might be
> - * in the process of modifying either member (next or prev)
> - *
>
Re: [PATCH v5 6/6] drm/bridge/sii8620: use micro-USB cable detection logic to detect MHL
On 2018년 02월 28일 22:44, Andrzej Hajda wrote:
> On 27.02.2018 23:26, Chanwoo Choi wrote:
>> Hi,
>>
>> On 2018년 02월 27일 21:05, Andrzej Hajda wrote:
>>> On 27.02.2018 12:08, Chanwoo Choi wrote:
Hi,
On 2018년 02월 27일 16:11, Andrzej Hajda wrote:
> From: Maciej Purski
>
> Currently MHL chip must be turned on permanently to detect MHL cable. It
> duplicates micro-USB controller's (MUIC) functionality and consumes
> unnecessary power. Lets use extcon attached to MUIC to enable MHL chip
> only if it detects MHL cable.
>
> Signed-off-by: Maciej Purski
> Signed-off-by: Andrzej Hajda
> ---
> v5: updated extcon API
>
> This is rework of the patch by Maciej with following changes:
> - use micro-USB port bindings to get extcon, instead of extcon property,
> - fixed remove sequence,
> - fixed extcon get state logic.
>
> Code finding extcon node is hacky IMO, I guess ultimately it should be
> done
> via some framework (maybe even extcon), or at least via helper, I hope it
> can stay as is until the proper solution will be merged.
>
> Signed-off-by: Andrzej Hajda
> ---
> drivers/gpu/drm/bridge/sil-sii8620.c | 97
> ++--
> 1 file changed, 94 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c
> b/drivers/gpu/drm/bridge/sil-sii8620.c
> index 9e785b8e0ea2..62b0adabcac2 100644
> --- a/drivers/gpu/drm/bridge/sil-sii8620.c
> +++ b/drivers/gpu/drm/bridge/sil-sii8620.c
> @@ -17,6 +17,7 @@
>
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -25,6 +26,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
>
> @@ -81,6 +83,10 @@ struct sii8620 {
> struct edid *edid;
> unsigned int gen2_write_burst:1;
> enum sii8620_mt_state mt_state;
> + struct extcon_dev *extcon;
> + struct notifier_block extcon_nb;
> + struct work_struct extcon_wq;
> + int cable_state;
> struct list_head mt_queue;
> struct {
> int r_size;
> @@ -2175,6 +2181,77 @@ static void sii8620_init_rcp_input_dev(struct
> sii8620 *ctx)
> ctx->rc_dev = rc_dev;
> }
>
> +static void sii8620_cable_out(struct sii8620 *ctx)
> +{
> + disable_irq(to_i2c_client(ctx->dev)->irq);
> + sii8620_hw_off(ctx);
> +}
> +
> +static void sii8620_extcon_work(struct work_struct *work)
> +{
> + struct sii8620 *ctx =
> + container_of(work, struct sii8620, extcon_wq);
> + int state = extcon_get_state(ctx->extcon, EXTCON_DISP_MHL);
> +
> + if (state == ctx->cable_state)
> + return;
> +
> + ctx->cable_state = state;
> +
> + if (state > 0)
> + sii8620_cable_in(ctx);
> + else
> + sii8620_cable_out(ctx);
> +}
> +
> +static int sii8620_extcon_notifier(struct notifier_block *self,
> + unsigned long event, void *ptr)
> +{
> + struct sii8620 *ctx =
> + container_of(self, struct sii8620, extcon_nb);
> +
> + schedule_work(&ctx->extcon_wq);
> +
> + return NOTIFY_DONE;
> +}
> +
> +static int sii8620_extcon_init(struct sii8620 *ctx)
> +{
> + struct extcon_dev *edev;
> + struct device_node *musb, *muic;
> + int ret;
> +
> + /* get micro-USB connector node */
> + musb = of_graph_get_remote_node(ctx->dev->of_node, 1, -1);
> + /* next get micro-USB Interface Controller node */
> + muic = of_get_next_parent(musb);
> +
> + if (!muic) {
> + dev_info(ctx->dev, "no extcon found, switching to 'always on'
> mode\n");
> + return 0;
> + }
> +
> + edev = extcon_find_edev_by_node(muic);
> + of_node_put(muic);
> + if (IS_ERR(edev)) {
> + if (PTR_ERR(edev) == -EPROBE_DEFER)
> + return -EPROBE_DEFER;
> + dev_err(ctx->dev, "Invalid or missing extcon\n");
> + return PTR_ERR(edev);
> + }
> +
> + ctx->extcon = edev;
> + ctx->extcon_nb.notifier_call = sii8620_extcon_notifier;
> + INIT_WORK(&ctx->extcon_wq, sii8620_extcon_work);
> + ret = extcon_register_notifier(edev, EXTCON_DISP_MHL, &ctx->extcon_nb);
You better to use devm_extcon_register_notifier().
>>> With devm version I risk that in case of device unbind notification will
>>> be called after .remove callback, it seems to me quite dangerous. Or am
>>> I missing something?
>> If you use the cancel_work_sync() in remove() instead of flush_work(),
>> you can use the 'devm_extcon_*'.
>
> cancel_work_sync() does not prevent works scheduled later from execution
> [1] and this scenario is possible with devm_extcon_register_notifier()
> and cancel_work_sync().
> So we end up with:
> sii8620_r
[PATCH v3 06/16] drm/sun4i: Release exclusive clock lock when disabling TCON
Currently exclusive TCON clock lock is never released, which, for
example, prevents changing resolution on HDMI.
In order to fix that, release clock when disabling TCON. TCON is always
disabled first before new mode is set.
Signed-off-by: Jernej Skrabec
---
drivers/gpu/drm/sun4i/sun4i_tcon.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index 1d714c06ec9d..7f6c4125c89f 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -102,10 +102,12 @@ static void sun4i_tcon_channel_set_status(struct
sun4i_tcon *tcon, int channel,
return;
}
- if (enabled)
+ if (enabled) {
clk_prepare_enable(clk);
- else
+ } else {
+ clk_rate_exclusive_put(clk);
clk_disable_unprepare(clk);
+ }
}
static void sun4i_tcon_lvds_set_status(struct sun4i_tcon *tcon,
--
2.16.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 03/16] clk: sunxi-ng: h3: h5: Allow some clocks to set parent rate
Some units have to be able to set it's own clock precisely to work
correctly. Allow them to do so by adding CLK_SET_RATE_PARENT flag.
Add this flag to DE, TCON and HDMI clocks.
Signed-off-by: Jernej Skrabec
---
drivers/clk/sunxi-ng/ccu-sun8i-h3.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-h3.c
b/drivers/clk/sunxi-ng/ccu-sun8i-h3.c
index b9f39078c0b2..77ed0b0ba681 100644
--- a/drivers/clk/sunxi-ng/ccu-sun8i-h3.c
+++ b/drivers/clk/sunxi-ng/ccu-sun8i-h3.c
@@ -452,11 +452,13 @@ static SUNXI_CCU_GATE(dram_ts_clk,"dram-ts",
"dram",
static const char * const de_parents[] = { "pll-periph0-2x", "pll-de" };
static SUNXI_CCU_M_WITH_MUX_GATE(de_clk, "de", de_parents,
-0x104, 0, 4, 24, 3, BIT(31), 0);
+0x104, 0, 4, 24, 3, BIT(31),
+CLK_SET_RATE_PARENT);
static const char * const tcon_parents[] = { "pll-video" };
static SUNXI_CCU_M_WITH_MUX_GATE(tcon_clk, "tcon", tcon_parents,
-0x118, 0, 4, 24, 3, BIT(31), 0);
+0x118, 0, 4, 24, 3, BIT(31),
+CLK_SET_RATE_PARENT);
static const char * const tve_parents[] = { "pll-de", "pll-periph1" };
static SUNXI_CCU_M_WITH_MUX_GATE(tve_clk, "tve", tve_parents,
@@ -487,7 +489,8 @@ static SUNXI_CCU_GATE(avs_clk, "avs",
"osc24M",
static const char * const hdmi_parents[] = { "pll-video" };
static SUNXI_CCU_M_WITH_MUX_GATE(hdmi_clk, "hdmi", hdmi_parents,
-0x150, 0, 4, 24, 2, BIT(31), 0);
+0x150, 0, 4, 24, 2, BIT(31),
+CLK_SET_RATE_PARENT);
static SUNXI_CCU_GATE(hdmi_ddc_clk,"hdmi-ddc", "osc24M",
0x154, BIT(31), 0);
--
2.16.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 12/16] drm/sun4i: Add support for H3 HDMI PHY variant
While A83T HDMI PHY seems to be just customized Synopsys HDMI PHY, H3
HDMI PHY is completely custom PHY.
However, they still have many things in common like clock and reset
setup, setting sync polarity and more.
Add support for H3 HDMI PHY variant.
While documentation exists for this PHY variant, it doesn't go in great
details. Because of that, almost all settings are copied from BSP linux
4.4. Interestingly, those settings are slightly different to those found
in a older BSP with Linux 3.4. For now, no user visible difference was
found between them.
Signed-off-by: Jernej Skrabec
---
drivers/gpu/drm/sun4i/Makefile | 1 +
drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h | 6 +
drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c | 264 -
drivers/gpu/drm/sun4i/sun8i_hdmi_phy_clk.c | 132 +++
4 files changed, 400 insertions(+), 3 deletions(-)
create mode 100644 drivers/gpu/drm/sun4i/sun8i_hdmi_phy_clk.c
diff --git a/drivers/gpu/drm/sun4i/Makefile b/drivers/gpu/drm/sun4i/Makefile
index 1610e748119b..330843ce4280 100644
--- a/drivers/gpu/drm/sun4i/Makefile
+++ b/drivers/gpu/drm/sun4i/Makefile
@@ -12,6 +12,7 @@ sun4i-drm-hdmi-y += sun4i_hdmi_tmds_clk.o
sun8i-drm-hdmi-y += sun8i_dw_hdmi.o
sun8i-drm-hdmi-y += sun8i_hdmi_phy.o
+sun8i-drm-hdmi-y += sun8i_hdmi_phy_clk.o
sun8i-mixer-y += sun8i_mixer.o sun8i_ui_layer.o \
sun8i_vi_layer.o sun8i_ui_scaler.o \
diff --git a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
index 49161326ea5a..79154f0f674a 100644
--- a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
+++ b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
@@ -146,6 +146,7 @@
struct sun8i_hdmi_phy;
struct sun8i_hdmi_phy_variant {
+ bool has_phy_clk;
void (*phy_init)(struct sun8i_hdmi_phy *phy);
void (*phy_disable)(struct dw_hdmi *hdmi,
struct sun8i_hdmi_phy *phy);
@@ -157,6 +158,9 @@ struct sun8i_hdmi_phy_variant {
struct sun8i_hdmi_phy {
struct clk *clk_bus;
struct clk *clk_mod;
+ struct clk *clk_phy;
+ struct clk *clk_pll0;
+ unsigned intrcal;
struct regmap *regs;
struct reset_control*rst_phy;
struct sun8i_hdmi_phy_variant *variant;
@@ -184,4 +188,6 @@ void sun8i_hdmi_phy_remove(struct sun8i_dw_hdmi *hdmi);
void sun8i_hdmi_phy_init(struct sun8i_hdmi_phy *phy);
const struct dw_hdmi_phy_ops *sun8i_hdmi_phy_get_ops(void);
+int sun8i_phy_clk_create(struct sun8i_hdmi_phy *phy, struct device *dev);
+
#endif /* _SUN8I_DW_HDMI_H_ */
diff --git a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
index 16889bc0c62d..5a52fc489a9d 100644
--- a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
+++ b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
@@ -3,6 +3,7 @@
* Copyright (c) 2018 Jernej Skrabec
*/
+#include
#include
#include "sun8i_dw_hdmi.h"
@@ -73,7 +74,148 @@ static int sun8i_hdmi_phy_config_a83t(struct dw_hdmi *hdmi,
dw_hdmi_phy_gen2_txpwron(hdmi, 1);
return 0;
-};
+}
+
+static int sun8i_hdmi_phy_config_h3(struct dw_hdmi *hdmi,
+ struct sun8i_hdmi_phy *phy,
+ unsigned int clk_rate)
+{
+ u32 pll_cfg1_init;
+ u32 pll_cfg2_init;
+ u32 ana_cfg1_end;
+ u32 ana_cfg2_init;
+ u32 ana_cfg3_init;
+ u32 b_offset = 0;
+ u32 val;
+
+ /* bandwidth / frequency independent settings */
+
+ pll_cfg1_init = SUN8I_HDMI_PHY_PLL_CFG1_LDO2_EN |
+ SUN8I_HDMI_PHY_PLL_CFG1_LDO1_EN |
+ SUN8I_HDMI_PHY_PLL_CFG1_LDO_VSET(7) |
+ SUN8I_HDMI_PHY_PLL_CFG1_UNKNOWN(1) |
+ SUN8I_HDMI_PHY_PLL_CFG1_PLLDBEN |
+ SUN8I_HDMI_PHY_PLL_CFG1_CS |
+ SUN8I_HDMI_PHY_PLL_CFG1_CP_S(2) |
+ SUN8I_HDMI_PHY_PLL_CFG1_CNT_INT(63) |
+ SUN8I_HDMI_PHY_PLL_CFG1_BWS;
+
+ pll_cfg2_init = SUN8I_HDMI_PHY_PLL_CFG2_SV_H |
+ SUN8I_HDMI_PHY_PLL_CFG2_VCOGAIN_EN |
+ SUN8I_HDMI_PHY_PLL_CFG2_SDIV2;
+
+ ana_cfg1_end = SUN8I_HDMI_PHY_ANA_CFG1_REG_SVBH(1) |
+ SUN8I_HDMI_PHY_ANA_CFG1_AMP_OPT |
+ SUN8I_HDMI_PHY_ANA_CFG1_EMP_OPT |
+ SUN8I_HDMI_PHY_ANA_CFG1_AMPCK_OPT |
+ SUN8I_HDMI_PHY_ANA_CFG1_EMPCK_OPT |
+ SUN8I_HDMI_PHY_ANA_CFG1_ENRCAL |
+ SUN8I_HDMI_PHY_ANA_CFG1_ENCALOG |
+ SUN8I_HDMI_PHY_ANA_CFG1_REG_SCKTMDS |
+ SUN8I_HDMI_PHY_ANA_CFG1_TMDSCLK_EN |
+ SUN8I_HDMI_PHY_ANA_CFG1_TXEN_MASK |
+
[PATCH 2/4] drm/pl111: Use max memory bandwidth for resolution
We were previously selecting 1024x768 and 32BPP as the default
set-up for the PL111 consumers.
This does not work on elder systems: the device tree bindings
support a property "max-memory-bandwidth" in bytes/second that
states that if you exceed this the memory bus will saturate.
The result is flickering and unstable images.
Parse the "max-memory-bandwidth" and respect it when
intializing the driver. On the RealView PB11MP, Versatile and
Integrator/CP we get a nice console as default with this code.
Signed-off-by: Linus Walleij
---
ChangeLog v2->v3:
- Account for the case where there is no bandwidth limitation
so priv->memory_bw is zero. Then just accept any modes.
ChangeLog v1->v2:
- Exploit the new .mode_valid() callback we added to the
simple KMS helper.
- Use the hardcoded bits per pixel per variant instead of
trying to be heuristic about this setting for now.
---
drivers/gpu/drm/pl111/pl111_display.c | 36 +++
drivers/gpu/drm/pl111/pl111_drm.h | 1 +
drivers/gpu/drm/pl111/pl111_drv.c | 6 ++
3 files changed, 43 insertions(+)
diff --git a/drivers/gpu/drm/pl111/pl111_display.c
b/drivers/gpu/drm/pl111/pl111_display.c
index d75923896609..577e61950e16 100644
--- a/drivers/gpu/drm/pl111/pl111_display.c
+++ b/drivers/gpu/drm/pl111/pl111_display.c
@@ -50,6 +50,41 @@ irqreturn_t pl111_irq(int irq, void *data)
return status;
}
+static enum drm_mode_status
+pl111_mode_valid(struct drm_crtc *crtc,
+const struct drm_display_mode *mode)
+{
+ struct drm_device *drm = crtc->dev;
+ struct pl111_drm_dev_private *priv = drm->dev_private;
+ u32 cpp = priv->variant->fb_bpp / 8;
+ u64 bw;
+
+ /*
+* We use the pixelclock to also account for interlaced modes, the
+* resulting bandwidth is in bytes per second.
+*/
+ bw = mode->clock * 1000; /* In Hz */
+ bw = bw * mode->hdisplay * mode->vdisplay * cpp;
+ bw = div_u64(bw, mode->htotal * mode->vtotal);
+
+ /*
+* If no bandwidth constraints, anything goes, else
+* check if we are too fast.
+*/
+ if (priv->memory_bw && (bw > priv->memory_bw)) {
+ DRM_INFO("%d x %d @ %d Hz, %d cpp, bw %llu too fast\n",
+mode->hdisplay, mode->vdisplay,
+mode->clock * 1000, cpp, bw);
+
+ return MODE_BAD;
+ }
+ DRM_INFO("%d x %d @ %d Hz, %d cpp, bw %llu bytes/s OK\n",
+mode->hdisplay, mode->vdisplay,
+mode->clock * 1000, cpp, bw);
+
+ return MODE_OK;
+}
+
static int pl111_display_check(struct drm_simple_display_pipe *pipe,
struct drm_plane_state *pstate,
struct drm_crtc_state *cstate)
@@ -344,6 +379,7 @@ static int pl111_display_prepare_fb(struct
drm_simple_display_pipe *pipe,
}
static const struct drm_simple_display_pipe_funcs pl111_display_funcs = {
+ .mode_valid = pl111_mode_valid,
.check = pl111_display_check,
.enable = pl111_display_enable,
.disable = pl111_display_disable,
diff --git a/drivers/gpu/drm/pl111/pl111_drm.h
b/drivers/gpu/drm/pl111/pl111_drm.h
index 360fbdd2203c..70b092670c04 100644
--- a/drivers/gpu/drm/pl111/pl111_drm.h
+++ b/drivers/gpu/drm/pl111/pl111_drm.h
@@ -65,6 +65,7 @@ struct pl111_drm_dev_private {
struct drm_simple_display_pipe pipe;
void *regs;
+ u32 memory_bw;
u32 ienb;
u32 ctrl;
/* The pixel clock (a reference to our clock divider off of CLCDCLK). */
diff --git a/drivers/gpu/drm/pl111/pl111_drv.c
b/drivers/gpu/drm/pl111/pl111_drv.c
index 73d252351438..b469aa317d9d 100644
--- a/drivers/gpu/drm/pl111/pl111_drv.c
+++ b/drivers/gpu/drm/pl111/pl111_drv.c
@@ -262,6 +262,12 @@ static int pl111_amba_probe(struct amba_device *amba_dev,
drm->dev_private = priv;
priv->variant = variant;
+ if (of_property_read_u32(dev->of_node, "max-memory-bandwidth",
+&priv->memory_bw)) {
+ dev_info(dev, "no max memory bandwidth specified, assume
unlimited\n");
+ priv->memory_bw = 0;
+ }
+
/* The two variants swap this register */
if (variant->is_pl110) {
priv->ienb = CLCD_PL110_IENB;
--
2.14.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/4] drm/pl111: Make the default BPP a per-variant variable
The PL110, Integrator and Versatile boards strongly prefer to
use 16 BPP even if other modes are supported, both to keep down
memory consumption and also to easier find a good match to
supported resolutions with consideration taken to the memory
bandwidth of the platforms.
Reviewed-by: Eric Anholt
Signed-off-by: Linus Walleij
---
drivers/gpu/drm/pl111/pl111_drm.h | 2 ++
drivers/gpu/drm/pl111/pl111_drv.c | 4 +++-
drivers/gpu/drm/pl111/pl111_versatile.c | 2 ++
3 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/pl111/pl111_drm.h
b/drivers/gpu/drm/pl111/pl111_drm.h
index 6d0e450e51b1..360fbdd2203c 100644
--- a/drivers/gpu/drm/pl111/pl111_drm.h
+++ b/drivers/gpu/drm/pl111/pl111_drm.h
@@ -43,6 +43,7 @@ struct drm_minor;
* @broken_vblank: the vblank IRQ is broken on this variant
* @formats: array of supported pixel formats on this variant
* @nformats: the length of the array of supported pixel formats
+ * @fb_bpp: desired bits per pixel on the default framebuffer
*/
struct pl111_variant_data {
const char *name;
@@ -52,6 +53,7 @@ struct pl111_variant_data {
bool broken_vblank;
const u32 *formats;
unsigned int nformats;
+ unsigned int fb_bpp;
};
struct pl111_drm_dev_private {
diff --git a/drivers/gpu/drm/pl111/pl111_drv.c
b/drivers/gpu/drm/pl111/pl111_drv.c
index 1231905150d0..73d252351438 100644
--- a/drivers/gpu/drm/pl111/pl111_drv.c
+++ b/drivers/gpu/drm/pl111/pl111_drv.c
@@ -192,7 +192,7 @@ static int pl111_modeset_init(struct drm_device *dev)
drm_mode_config_reset(dev);
- drm_fb_cma_fbdev_init(dev, 32, 0);
+ drm_fb_cma_fbdev_init(dev, priv->variant->fb_bpp, 0);
drm_kms_helper_poll_init(dev);
@@ -341,6 +341,7 @@ static const struct pl111_variant_data pl110_variant = {
.is_pl110 = true,
.formats = pl110_pixel_formats,
.nformats = ARRAY_SIZE(pl110_pixel_formats),
+ .fb_bpp = 16,
};
/* RealView, Versatile Express etc use this modern variant */
@@ -365,6 +366,7 @@ static const struct pl111_variant_data pl111_variant = {
.name = "PL111",
.formats = pl111_pixel_formats,
.nformats = ARRAY_SIZE(pl111_pixel_formats),
+ .fb_bpp = 32,
};
static const struct amba_id pl111_id_table[] = {
diff --git a/drivers/gpu/drm/pl111/pl111_versatile.c
b/drivers/gpu/drm/pl111/pl111_versatile.c
index 11024ad64181..9825f6d52788 100644
--- a/drivers/gpu/drm/pl111/pl111_versatile.c
+++ b/drivers/gpu/drm/pl111/pl111_versatile.c
@@ -241,6 +241,7 @@ static const struct pl111_variant_data pl110_integrator = {
.broken_vblank = true,
.formats = pl110_integrator_pixel_formats,
.nformats = ARRAY_SIZE(pl110_integrator_pixel_formats),
+ .fb_bpp = 16,
};
/*
@@ -253,6 +254,7 @@ static const struct pl111_variant_data pl110_versatile = {
.external_bgr = true,
.formats = pl110_versatile_pixel_formats,
.nformats = ARRAY_SIZE(pl110_versatile_pixel_formats),
+ .fb_bpp = 16,
};
int pl111_versatile_init(struct device *dev, struct pl111_drm_dev_private
*priv)
--
2.14.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/4] drm/pl111: RealView and Versatile Express
This is the base for finally getting RealView and Versatile Express supported in the PL111 DRM driver. We have then moved all the way up from the first ARM Integrator versions to the last Versatile Express reference designs using PL111. After this, forked hardware such as Nomadik and SPEAr remains to be moved over. Some infrastructure for adjusting depth (ARGB5551) etc on the Integrator and some bridge fixups are still needed but this is the core of the support for these platforms and the rest can be done on top before switching over. Also the Versatile Express CLCD on the motherboard has a dedicated video memory, and cannot use CMA (ha! complex!) and I will need to figure out a way to work around that. The CLCDs synthesized on the core tiles for CA9 work fine with this though. Linus Walleij (4): drm/pl111: Make the default BPP a per-variant variable drm/pl111: Use max memory bandwidth for resolution drm/pl111: Handle the RealView variant separately drm/pl111: Support the Versatile Express drivers/gpu/drm/pl111/Makefile | 1 + drivers/gpu/drm/pl111/pl111_display.c | 36 +++ drivers/gpu/drm/pl111/pl111_drm.h | 6 +- drivers/gpu/drm/pl111/pl111_drv.c | 10 ++- drivers/gpu/drm/pl111/pl111_versatile.c | 80 +++- drivers/gpu/drm/pl111/pl111_vexpress.c | 106 drivers/gpu/drm/pl111/pl111_vexpress.h | 22 +++ 7 files changed, 258 insertions(+), 3 deletions(-) create mode 100644 drivers/gpu/drm/pl111/pl111_vexpress.c create mode 100644 drivers/gpu/drm/pl111/pl111_vexpress.h -- 2.14.3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/4] drm/pl111: Support the Versatile Express
The Versatile Express uses a special configuration controller
deeply embedded in the system motherboard FPGA to multiplex the
two to three (!) CLCD instances out to the single SiI9022
bridge.
Set up an extra file with the logic to probe to the FPGA mux
register on the system controller bus, then parse the memory
range argument to figure out what path the CLCD signal is
actually taking, and set up the mux accordingly.
If there is a CLCD instance on the core tile (the daughterboard
with the CPUs fitted) then that CLCD instance will take
precedence since it can address all memory.
Scale down the Versatile Express to 16BPP so we can support a
1024x768 display despite the bus bandwidth restrictions on this
platform.
Cc: Liviu Dudau
Cc: Pawel Moll
Signed-off-by: Linus Walleij
---
drivers/gpu/drm/pl111/Makefile | 1 +
drivers/gpu/drm/pl111/pl111_drm.h | 3 +-
drivers/gpu/drm/pl111/pl111_versatile.c | 48 ++-
drivers/gpu/drm/pl111/pl111_vexpress.c | 106
drivers/gpu/drm/pl111/pl111_vexpress.h | 22 +++
5 files changed, 178 insertions(+), 2 deletions(-)
create mode 100644 drivers/gpu/drm/pl111/pl111_vexpress.c
create mode 100644 drivers/gpu/drm/pl111/pl111_vexpress.h
diff --git a/drivers/gpu/drm/pl111/Makefile b/drivers/gpu/drm/pl111/Makefile
index 9c5e8dba8ac6..19a8189dc54f 100644
--- a/drivers/gpu/drm/pl111/Makefile
+++ b/drivers/gpu/drm/pl111/Makefile
@@ -3,6 +3,7 @@ pl111_drm-y += pl111_display.o \
pl111_versatile.o \
pl111_drv.o
+pl111_drm-$(CONFIG_ARCH_VEXPRESS) += pl111_vexpress.o
pl111_drm-$(CONFIG_DEBUG_FS) += pl111_debugfs.o
obj-$(CONFIG_DRM_PL111) += pl111_drm.o
diff --git a/drivers/gpu/drm/pl111/pl111_drm.h
b/drivers/gpu/drm/pl111/pl111_drm.h
index 70b092670c04..e7c5d4a09238 100644
--- a/drivers/gpu/drm/pl111/pl111_drm.h
+++ b/drivers/gpu/drm/pl111/pl111_drm.h
@@ -64,7 +64,8 @@ struct pl111_drm_dev_private {
struct drm_bridge *bridge;
struct drm_simple_display_pipe pipe;
- void *regs;
+ void __iomem *clcd_memory;
+ void __iomem *regs;
u32 memory_bw;
u32 ienb;
u32 ctrl;
diff --git a/drivers/gpu/drm/pl111/pl111_versatile.c
b/drivers/gpu/drm/pl111/pl111_versatile.c
index f15391d994b6..0170c34fb653 100644
--- a/drivers/gpu/drm/pl111/pl111_versatile.c
+++ b/drivers/gpu/drm/pl111/pl111_versatile.c
@@ -1,12 +1,14 @@
#include
#include
#include
+#include
#include
#include
#include
#include
#include
#include "pl111_versatile.h"
+#include "pl111_vexpress.h"
#include "pl111_drm.h"
static struct regmap *versatile_syscon_map;
@@ -22,6 +24,7 @@ enum versatile_clcd {
REALVIEW_CLCD_PB11MP,
REALVIEW_CLCD_PBA8,
REALVIEW_CLCD_PBX,
+ VEXPRESS_CLCD_V2M,
};
static const struct of_device_id versatile_clcd_of_match[] = {
@@ -53,6 +56,10 @@ static const struct of_device_id versatile_clcd_of_match[] =
{
.compatible = "arm,realview-pbx-syscon",
.data = (void *)REALVIEW_CLCD_PBX,
},
+ {
+ .compatible = "arm,vexpress-muxfpga",
+ .data = (void *)VEXPRESS_CLCD_V2M,
+ },
{},
};
@@ -286,12 +293,26 @@ static const struct pl111_variant_data pl111_realview = {
.fb_bpp = 16,
};
+/*
+ * Versatile Express PL111 variant, again we just push the maximum
+ * BPP to 16 to be able to get 1024x768 without saturating the memory
+ * bus. The clockdivider also seems broken on the Versatile Express.
+ */
+static const struct pl111_variant_data pl111_vexpress = {
+ .name = "PL111 Versatile Express",
+ .formats = pl111_realview_pixel_formats,
+ .nformats = ARRAY_SIZE(pl111_realview_pixel_formats),
+ .fb_bpp = 16,
+ .broken_clockdivider = true,
+};
+
int pl111_versatile_init(struct device *dev, struct pl111_drm_dev_private
*priv)
{
const struct of_device_id *clcd_id;
enum versatile_clcd versatile_clcd_type;
struct device_node *np;
struct regmap *map;
+ int ret;
np = of_find_matching_node_and_match(NULL, versatile_clcd_of_match,
&clcd_id);
@@ -301,7 +322,25 @@ int pl111_versatile_init(struct device *dev, struct
pl111_drm_dev_private *priv)
}
versatile_clcd_type = (enum versatile_clcd)clcd_id->data;
- map = syscon_node_to_regmap(np);
+ /* Versatile Express special handling */
+ if (versatile_clcd_type == VEXPRESS_CLCD_V2M) {
+ struct platform_device *pdev;
+
+ /* Call into deep Vexpress configuration API */
+ pdev = of_find_device_by_node(np);
+ if (!pdev) {
+ dev_err(dev, "can't find the sysreg device,
deferring\n");
+ return -EPROBE_DEFER;
+ }
+ map = dev_get_drvdata(&pdev->dev);
+ if (!map) {
+ de
[PATCH 3/4] drm/pl111: Handle the RealView variant separately
We want to cut down the default bpp to 16 on the RealView so
we can have a 1024x768 framebuffer console by default. The
memory bandwidth limitations makes this not work with the
PL111 default of 32bpp.
This builds on top of the earlier patches making the
framebuffer default bpp a per-variant variable.
Signed-off-by: Linus Walleij
---
drivers/gpu/drm/pl111/pl111_versatile.c | 30 ++
1 file changed, 30 insertions(+)
diff --git a/drivers/gpu/drm/pl111/pl111_versatile.c
b/drivers/gpu/drm/pl111/pl111_versatile.c
index 9825f6d52788..f15391d994b6 100644
--- a/drivers/gpu/drm/pl111/pl111_versatile.c
+++ b/drivers/gpu/drm/pl111/pl111_versatile.c
@@ -230,6 +230,23 @@ static const u32 pl110_versatile_pixel_formats[] = {
DRM_FORMAT_XRGB1555,
};
+static const u32 pl111_realview_pixel_formats[] = {
+ DRM_FORMAT_ABGR,
+ DRM_FORMAT_XBGR,
+ DRM_FORMAT_ARGB,
+ DRM_FORMAT_XRGB,
+ DRM_FORMAT_BGR565,
+ DRM_FORMAT_RGB565,
+ DRM_FORMAT_ABGR1555,
+ DRM_FORMAT_XBGR1555,
+ DRM_FORMAT_ARGB1555,
+ DRM_FORMAT_XRGB1555,
+ DRM_FORMAT_ABGR,
+ DRM_FORMAT_XBGR,
+ DRM_FORMAT_ARGB,
+ DRM_FORMAT_XRGB,
+};
+
/*
* The Integrator variant is a PL110 with a bunch of broken, or not
* yet implemented features
@@ -257,6 +274,18 @@ static const struct pl111_variant_data pl110_versatile = {
.fb_bpp = 16,
};
+/*
+ * RealView PL111 variant, the only real difference from the vanilla
+ * PL111 is that we select 16bpp framebuffer by default to be able
+ * to get 1024x768 without saturating the memory bus.
+ */
+static const struct pl111_variant_data pl111_realview = {
+ .name = "PL111 RealView",
+ .formats = pl111_realview_pixel_formats,
+ .nformats = ARRAY_SIZE(pl111_realview_pixel_formats),
+ .fb_bpp = 16,
+};
+
int pl111_versatile_init(struct device *dev, struct pl111_drm_dev_private
*priv)
{
const struct of_device_id *clcd_id;
@@ -306,6 +335,7 @@ int pl111_versatile_init(struct device *dev, struct
pl111_drm_dev_private *priv)
case REALVIEW_CLCD_PBA8:
case REALVIEW_CLCD_PBX:
versatile_syscon_map = map;
+ priv->variant = &pl111_realview;
priv->variant_display_enable = pl111_realview_clcd_enable;
priv->variant_display_disable = pl111_realview_clcd_disable;
dev_info(dev, "set up callbacks for RealView PL111\n");
--
2.14.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: v4.16-rc0: missing includes in framebuffers break N900 compilation
On Mon 2018-02-26 16:05:53, Tomi Valkeinen wrote: > v4.16-rc1 has a fix (b9058afcd6c7). Yep, thanks. I was bisecting sound problem on N900, so this hit me... Pavel > On 26/02/18 15:00, Pavel Machek wrote: > > I needed this to get -rc0 to compile. > > > > Signed-off-by: Pavel Machek > > > > > > diff --git a/drivers/video/fbdev/omap2/omapfb/dss/dss.c > > b/drivers/video/fbdev/omap2/omapfb/dss/dss.c > > index 48c6500..990f1c9 100644 > > --- a/drivers/video/fbdev/omap2/omapfb/dss/dss.c > > +++ b/drivers/video/fbdev/omap2/omapfb/dss/dss.c > > @@ -38,6 +38,7 @@ > > #include > > #include > > #include > > +#include > > #include > > #include > > > > diff --git a/drivers/video/fbdev/omap2/omapfb/dss/hdmi_phy.c > > b/drivers/video/fbdev/omap2/omapfb/dss/hdmi_phy.c > > index 9a13c35..4862b12 100644 > > --- a/drivers/video/fbdev/omap2/omapfb/dss/hdmi_phy.c > > +++ b/drivers/video/fbdev/omap2/omapfb/dss/hdmi_phy.c > > @@ -12,6 +12,7 @@ > > #include > > #include > > #include > > +#include > > #include > > #include > > > > diff --git a/drivers/video/fbdev/omap2/omapfb/dss/hdmi_pll.c > > b/drivers/video/fbdev/omap2/omapfb/dss/hdmi_pll.c > > index eac3665..39014e2 100644 > > --- a/drivers/video/fbdev/omap2/omapfb/dss/hdmi_pll.c > > +++ b/drivers/video/fbdev/omap2/omapfb/dss/hdmi_pll.c > > @@ -15,6 +15,7 @@ > > #include > > #include > > #include > > +#include > > #include > > > > #include > > diff --git a/drivers/video/fbdev/omap2/omapfb/dss/hdmi_wp.c > > b/drivers/video/fbdev/omap2/omapfb/dss/hdmi_wp.c > > index 705373e..e93e7a7 100644 > > --- a/drivers/video/fbdev/omap2/omapfb/dss/hdmi_wp.c > > +++ b/drivers/video/fbdev/omap2/omapfb/dss/hdmi_wp.c > > @@ -15,6 +15,7 @@ > > #include > > #include > > #include > > +#include > > > > #include "dss.h" > > #include "hdmi.h" > > > -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3] bridge: Elaborate a bit on dumb VGA bridges in Kconfig
It's better if we explain a bit that this pertains to non-programmable VGA DAC bridges. Reviewed-by: Laurent Pinchart Signed-off-by: Linus Walleij --- ChangeLog v2->v3: - Fix wording and commit message. - Collect Laurent's review tag. ChangeLog v1->v2: - Write that these bridges are non-programmable rather than discrete, as that reflects the name of the bridge being "dumb". Discrete is wrong as it has a specific electronic meaning, as in "non-integrated" and this is integrated. --- drivers/gpu/drm/bridge/Kconfig | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig index 3b99d5a06c16..3aa65bdecb0e 100644 --- a/drivers/gpu/drm/bridge/Kconfig +++ b/drivers/gpu/drm/bridge/Kconfig @@ -30,7 +30,8 @@ config DRM_DUMB_VGA_DAC depends on OF select DRM_KMS_HELPER help - Support for RGB to VGA DAC based bridges + Support for non-programmable RGB to VGA DAC bridges, such as ADI + ADV7123, TI THS8134 and THS8135 or passive resistor ladder DACs. config DRM_LVDS_ENCODER tristate "Transparent parallel to LVDS encoder support" -- 2.14.3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 00/16] Implement H3/H5 HDMI driver
On Thu, Mar 01, 2018 at 10:34:26PM +0100, Jernej Skrabec wrote: > This series implements H3/H5 HDMI driver. It was tested on OrangePi 2 (H3), > OrangePi Plus2e (H3) and OrangePi PC2 (H5) with many resolutions and it > works well. > > Code is based on linux-next, next-20180228 tag. Applied everything, thanks! Maxime -- Maxime Ripard, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 105317] The GPU Vega 56 was hang while try to pass #GraphicsFuzz shader15 test
https://bugs.freedesktop.org/show_bug.cgi?id=105317 Michel Dänzer changed: What|Removed |Added Product|DRI |Mesa QA Contact||dri-devel@lists.freedesktop ||.org Version|XOrg git|git Component|DRM/AMDgpu |Drivers/Gallium/radeonsi -- 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 08/10] drm/panel: Add Huarui LHR050H41 panel driver
Hi, On Wed, Feb 21, 2018 at 11:36:10PM +0800, Chen-Yu Tsai wrote: > On Wed, Feb 21, 2018 at 5:20 PM, Maxime Ripard > wrote: > > From: Maxime Ripard > > > > The LHR050H41 panel is the panel shipped with the BananaPi M2-Magic. Add a > > driver for it. > > So I distinctly remember questioning the vendor name the first time. > I would just use Bananapi as the vendor name instead. Ack. > > +config DRM_PANEL_HUARUI_LHR050H41 > > + tristate "Huarui LHR050H41 panel" > > + depends on OF > > + depends on DRM_MIPI_DSI > > + depends on BACKLIGHT_CLASS_DEVICE > > + help > > + Say Y if you want to enable support for the Huarui Lighting > > + LHR05041 DSI panel. The panel has a 1280x720 resolution. > > + > > And it seems this panel is driven by an ILI9881C from Ilitek. So > maybe you could make the panel driver more like the IL9322, as in > having common code for the driver IC, then a data structure tied > to actual panel compatible strings to handle any quirks. > > The datasheet can be found simply by googling the part ID, or here: > > > http://en.startek-lcd.com/res/starteklcden/pdres/201706/20170617115241070.pdf > > This should help with the init command sequence. > > I also found this: > > http://www.ampdisplay.com/documents/pdf/AM-7201280ETZQW-00H.pdf > > which might or might not be the same panel. > > Now the IL9332 driver simply uses the device model (Dlink DIR-685) > as part of the compatible string. I guess we can create an ili9881c driver then, with the lhr050h41 compatible. I'm not sure there's much more we can do at this point, since in order to know the set of quirks to associate to each compatible, we'd need to have a second panel. Thanks! Maxime -- Maxime Ripard, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 105324] R9 285 weston hangs since drm/amd/pp: Fix bug that dpm level was not really locked
https://bugs.freedesktop.org/show_bug.cgi?id=105324 Bug ID: 105324 Summary: R9 285 weston hangs since drm/amd/pp: Fix bug that dpm level was not really locked Product: DRI Version: DRI git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: adf.li...@gmail.com R9 285 Tonga, testing with amdgpu.dc=0 on agd5f 4.17-wip Since commit a02497b73218f10f237d98fb10d34d0baed607a0 Author: Rex Zhu Date: Fri Feb 9 16:47:53 2018 +0800 drm/amd/pp: Fix bug that dpm level was not really locked Lock the dpm levels when we use SW method to modify the dpm tables directly to avoid a possible race with the smu. weston may hang display on start/quit/vt switch SysRq works and logged will be errors like - Mar 2 00:19:03 ph4 kernel: amdgpu: [powerplay] Mar 2 00:19:03 ph4 kernel: failed to send message 18b ret is 0 Mar 2 00:19:03 ph4 kernel: amdgpu: [powerplay] Mar 2 00:19:03 ph4 kernel: failed to send pre message 18a ret is 0 Mar 2 00:19:04 ph4 kernel: amdgpu: [powerplay] Mar 2 00:19:04 ph4 kernel: failed to send message 18a ret is 0 Mar 2 00:19:04 ph4 kernel: amdgpu: [powerplay] Mar 2 00:19:04 ph4 kernel: failed to send pre message 18c ret is 0 Mar 2 00:19:04 ph4 kernel: amdgpu: [powerplay] Mar 2 00:19:04 ph4 kernel: failed to send message 18c ret is 0 Mar 2 00:19:05 ph4 kernel: amdgpu: [powerplay] Mar 2 00:19:05 ph4 kernel: failed to send pre message 145 ret is 0 Mar 2 00:19:05 ph4 kernel: amdgpu: [powerplay] Mar 2 00:19:05 ph4 kernel: failed to send message 145 ret is 0 Mar 2 00:19:06 ph4 kernel: amdgpu: [powerplay] Mar 2 00:19:06 ph4 kernel: failed to send pre message 146 ret is 0 Mar 2 00:19:06 ph4 kernel: amdgpu: [powerplay] Mar 2 00:19:06 ph4 kernel: failed to send message 146 ret is 0 Mar 2 00:19:07 ph4 kernel: amdgpu: [powerplay] Mar 2 00:19:07 ph4 kernel: failed to send pre message 148 ret is 0 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/bridge/synopsys: dsi: readl_poll_timeout return value clean up
On 01.03.2018 10:00, Philippe CORNU wrote:
> Hi Archit, Andrzej & Laurent,
>
> May I ask you please your feedback on this small patch?
> Many thanks,
>
> Philippe :-)
>
> On 02/04/2018 10:36 PM, Philippe Cornu wrote:
>> The readl_poll_timeout() return value is 0 in case of success
>> so it is better to detect errors without taking care of the
>> return value sign.
>>
>> Signed-off-by: Philippe Cornu
The patch is of course correct. However I am not sure if necessary. For
sure functionally it does not change anything.
AFAIK kernel CodingStyle says nothing about it, so I suppose it is
matter of personal taste.
Anyway I can give it:
Reviewed-by: Andrzej Hajda
--
Regards
Andrzej
>> ---
>> drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 10 +-
>> 1 file changed, 5 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
>> b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
>> index 65aeb3f78b48..4d0e8471a15c 100644
>> --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
>> +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
>> @@ -342,7 +342,7 @@ static int dw_mipi_dsi_gen_pkt_hdr_write(struct
>> dw_mipi_dsi *dsi, u32 hdr_val)
>> ret = qq(dsi->base + DSI_CMD_PKT_STATUS,
>> val, !(val & GEN_CMD_FULL), 1000,
>> CMD_PKT_STATUS_TIMEOUT_US);
>> -if (ret < 0) {
>> +if (ret) {
>> dev_err(dsi->dev, "failed to get available command FIFO\n");
>> return ret;
>> }
>> @@ -353,7 +353,7 @@ static int dw_mipi_dsi_gen_pkt_hdr_write(struct
>> dw_mipi_dsi *dsi, u32 hdr_val)
>> ret = readl_poll_timeout(dsi->base + DSI_CMD_PKT_STATUS,
>> val, (val & mask) == mask,
>> 1000, CMD_PKT_STATUS_TIMEOUT_US);
>> -if (ret < 0) {
>> +if (ret) {
>> dev_err(dsi->dev, "failed to write command FIFO\n");
>> return ret;
>> }
>> @@ -385,7 +385,7 @@ static int dw_mipi_dsi_write(struct dw_mipi_dsi *dsi,
>> ret = readl_poll_timeout(dsi->base + DSI_CMD_PKT_STATUS,
>> val, !(val & GEN_PLD_W_FULL), 1000,
>> CMD_PKT_STATUS_TIMEOUT_US);
>> -if (ret < 0) {
>> +if (ret) {
>> dev_err(dsi->dev,
>> "failed to get available write payload FIFO\n");
>> return ret;
>> @@ -716,13 +716,13 @@ static void dw_mipi_dsi_dphy_enable(struct dw_mipi_dsi
>> *dsi)
>>
>> ret = readl_poll_timeout(dsi->base + DSI_PHY_STATUS, val,
>> val & PHY_LOCK, 1000, PHY_STATUS_TIMEOUT_US);
>> -if (ret < 0)
>> +if (ret)
>> DRM_DEBUG_DRIVER("failed to wait phy lock state\n");
>>
>> ret = readl_poll_timeout(dsi->base + DSI_PHY_STATUS,
>> val, val & PHY_STOP_STATE_CLK_LANE, 1000,
>> PHY_STATUS_TIMEOUT_US);
>> -if (ret < 0)
>> +if (ret)
>> DRM_DEBUG_DRIVER("failed to wait phy clk lane stop state\n");
>> }
>>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 105262] [R600] [BISECTED] ttf fonts are invisible in many programs
https://bugs.freedesktop.org/show_bug.cgi?id=105262 --- Comment #10 from LoneVVolf --- The first bad commit was submitted by Dave Airlie and reviewed by Roland Scheidegger Added Roland Scheidegger to CC List. -- 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/2] Chunk splitting of spi transfers
On Sun, Feb 25, 2018 at 02:19:10PM +0100, Lukas Wunner wrote: > [cc += linux-rpi-ker...@lists.infradead.org] > > On Sat, Feb 24, 2018 at 06:15:59PM +, Meghana Madhyastha wrote: > > I've added bcm2835_spi_transfer_one_message in spi-bcm2835. This calls > > spi_split_transfers_maxsize to split large chunks for spi dma transfers. > > I then removed chunk splitting in the tinydrm spi helper (as now the core > > is handling the chunk splitting). However, although the SPI HW should be > > able to accomodate up to 65535 bytes for dma transfers, the splitting of > > chunks to 65535 bytes results in a dma transfer time out error. However, > > when the chunks are split to < 64 bytes it seems to work fine. > > Hm, that is really odd, how did you test this exactly, what did you > use as SPI slave? It contradicts our own experience, we're using > Micrel KSZ8851 Ethernet chips as SPI slave on spi0 of a BCM2837 > and can send/receive messages via DMA to the tune of several hundred > bytes without any issues. In fact, for messages < 96 bytes, DMA is > not used at all, so you've probably been using interrupt mode, > see the BCM2835_SPI_DMA_MIN_LENGTH macro in spi-bcm2835.c. Hi Lukas, I think you are right. I checked it and its not using the DMA mode which is why its working with 64 bytes. Noralf, that leaves us back to the initial time out problem. I've tried doing the message splitting in spi_sync as well as spi_pump_messages. Martin had explained that DMA will wait for the SPI HW to set the send_more_data line, but the SPI-HW itself will stop triggering it when SPI_LEN is 0 causing DMA to wait forever. I thought if we split it before itself, the SPI_LEN will not go to zero thus preventing this problem, however it didn't work and started hanging. So I'm a little uncertain as to how to proceed and debug what exactly has caused the time out due to the asynchronous methods. Thanks and regards, Meghana > Thanks, > > Lukas ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/sun4i: add lvds mode_valid function
Hi,
Il 01/03/2018 10:57, Maxime Ripard ha scritto:
On Wed, Feb 28, 2018 at 06:53:52PM +0100, Giulio Benetti wrote:
static struct drm_connector_helper_funcs sun4i_lvds_con_helper_funcs = {
.get_modes = sun4i_lvds_get_modes,
+ .mode_valid = sun4i_lvds_mode_valid,
};
This should be on the encoder, not the connector.
I've seen it is bound to connector in rgb and to encoder in hdmi.
Is it correct rgb mode_valid under connector funcs?
Otherwise I send a patch also for that one.
Maxime
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Giulio Benetti
CTO
MICRONOVA SRL
Sede: Via A. Niedda 3 - 35010 Vigonza (PD)
Tel. 049/8931563 - Fax 049/8931346
Cod.Fiscale - P.IVA 02663420285
Capitale Sociale € 26.000 i.v.
Iscritta al Reg. Imprese di Padova N. 02663420285
Numero R.E.A. 258642
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/sun4i: Handle DRM_BUS_FLAG_PIXDATA_*EDGE
Hi,
Il 01/03/2018 10:39, Maxime Ripard ha scritto:
On Wed, Feb 28, 2018 at 05:14:52PM +0100, Giulio Benetti wrote:
Handle both positive and negative dclk polarity,
according to bus_flags.
Signed-off-by: Giulio Benetti
---
drivers/gpu/drm/sun4i/sun4i_tcon.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index aaf911a..534e5ee 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include
@@ -340,6 +341,9 @@ static void sun4i_tcon0_mode_set_lvds(struct sun4i_tcon *tcon,
static void sun4i_tcon0_mode_set_rgb(struct sun4i_tcon *tcon,
const struct drm_display_mode *mode)
{
+ struct drm_panel *panel = tcon->panel;
+ struct drm_connector *connector = panel->connector;
+ struct drm_display_info display_info = connector->display_info;
unsigned int bp, hsync, vsync;
u8 clk_delay;
u32 val = 0;
@@ -395,8 +399,15 @@ static void sun4i_tcon0_mode_set_rgb(struct sun4i_tcon
*tcon,
if (mode->flags & DRM_MODE_FLAG_PVSYNC)
val |= SUN4I_TCON0_IO_POL_VSYNC_POSITIVE;
+ if (display_info.bus_flags & DRM_BUS_FLAG_PIXDATA_POSEDGE)
+ clk_set_phase(tcon->dclk, 240);
+
+ if (display_info.bus_flags & DRM_BUS_FLAG_PIXDATA_NEGEDGE)
+ clk_set_phase(tcon->dclk, 0);
+
This needs to have a whole bunch of comments here. We want to have
basically the whole discussion we had by mail previously about this in
there.
And the same goes for your commit log.
Ok, I follow asap with V2 patch describing everything we told on
previous thread.
regmap_update_bits(tcon->regs, SUN4I_TCON0_IO_POL_REG,
- SUN4I_TCON0_IO_POL_HSYNC_POSITIVE |
SUN4I_TCON0_IO_POL_VSYNC_POSITIVE,
+ SUN4I_TCON0_IO_POL_HSYNC_POSITIVE |
+ SUN4I_TCON0_IO_POL_VSYNC_POSITIVE,
val);
This has nothing to do with your patch.
Yes, sorry, I've seen it now, I remove it on V2 patch
Maxime
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Giulio Benetti
CTO
MICRONOVA SRL
Sede: Via A. Niedda 3 - 35010 Vigonza (PD)
Tel. 049/8931563 - Fax 049/8931346
Cod.Fiscale - P.IVA 02663420285
Capitale Sociale € 26.000 i.v.
Iscritta al Reg. Imprese di Padova N. 02663420285
Numero R.E.A. 258642
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/4] drm/pl111: RealView and Versatile Express
Hi Linus, On 02/03/18 09:09, Linus Walleij wrote: This is the base for finally getting RealView and Versatile Express supported in the PL111 DRM driver. We have then moved all the way up from the first ARM Integrator versions to the last Versatile Express reference designs using PL111. After this, forked hardware such as Nomadik and SPEAr remains to be moved over. Some infrastructure for adjusting depth (ARGB5551) etc on the Integrator and some bridge fixups are still needed but this is the core of the support for these platforms and the rest can be done on top before switching over. Also the Versatile Express CLCD on the motherboard has a dedicated video memory, and cannot use CMA (ha! complex!) and I will need to figure out a way to work around that. The CLCDs synthesized on the core tiles for CA9 work fine with this though. Out of curiosity, what's the issue with declaring the VRAM as a CMA region? That's certainly worked for stuff like local RAM on FPGA tiles in the past, and I can't think offhand of any way in which VExpress is wildly different (but I am of course open to being wrong...) Robin. Linus Walleij (4): drm/pl111: Make the default BPP a per-variant variable drm/pl111: Use max memory bandwidth for resolution drm/pl111: Handle the RealView variant separately drm/pl111: Support the Versatile Express drivers/gpu/drm/pl111/Makefile | 1 + drivers/gpu/drm/pl111/pl111_display.c | 36 +++ drivers/gpu/drm/pl111/pl111_drm.h | 6 +- drivers/gpu/drm/pl111/pl111_drv.c | 10 ++- drivers/gpu/drm/pl111/pl111_versatile.c | 80 +++- drivers/gpu/drm/pl111/pl111_vexpress.c | 106 drivers/gpu/drm/pl111/pl111_vexpress.h | 22 +++ 7 files changed, 258 insertions(+), 3 deletions(-) create mode 100644 drivers/gpu/drm/pl111/pl111_vexpress.c create mode 100644 drivers/gpu/drm/pl111/pl111_vexpress.h ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8 4/8] drm/rockchip: dw-mipi-dsi: Fix error handling path
Hi Enric,
Am Freitag, 2. März 2018, 13:09:02 CET schrieb Enric Balletbo i Serra:
> Hi Heiko,
>
> On 01/03/18 16:50, Heiko Stübner wrote:
> > Hi Jeffy, Thierry, Enric,
> >
> > Am Mittwoch, 10. Januar 2018, 17:23:44 CET schrieb Thierry Escande:
> >> From: Jeffy Chen
> >>
> >> Add missing pm_runtime_disable() in bind()'s error handling path.
> >>
> >> Also cleanup encoder & connector in unbind().
> >
> > Can you please split all these surprise "Also" sections into separate
> > patches?
> >
>
> I'll take a look.
>
> > It looks like this is true for all following patch to some degree and
> > the inno-hdmi patch even has a unbind reordering-change without
> > mentioning it in the commit message.
> >
>
> Actually, I think this patch is not correct against current mainline, see
> below.
>
> >
> > Thanks
> > Heiko
> >
> >> Fixes: 80a9a059d4e4 ("drm/rockchip/dsi: add dw-mipi power domain support")
> >> Signed-off-by: Jeffy Chen
> >> Signed-off-by: Thierry Escande
> >> ---
> >> drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 21 +
> >> 1 file changed, 13 insertions(+), 8 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> >> b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c index b1fe0639227e..78e6b7919bf7
> >> 100644
> >> --- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> >> +++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> >> @@ -1282,7 +1282,7 @@ static int dw_mipi_dsi_bind(struct device *dev,
> >> struct
> >> device *master, ret = dw_mipi_dsi_register(drm, dsi);
> >>if (ret) {
> >>DRM_DEV_ERROR(dev, "Failed to register mipi_dsi: %d\n", ret);
> >> - goto err_pllref;
> >> + goto err_disable_pllref;
> >>}
> >>
> >>dsi->dsi_host.ops = &dw_mipi_dsi_host_ops;
> >> @@ -1290,24 +1290,25 @@ static int dw_mipi_dsi_bind(struct device *dev,
> >> struct device *master, ret = mipi_dsi_host_register(&dsi->dsi_host);
> >>if (ret) {
> >>DRM_DEV_ERROR(dev, "Failed to register MIPI host: %d\n", ret);
> >> - goto err_cleanup;
> >> + goto err_disable_pm_runtime;
> >>}
> >>
> >>if (!dsi->panel) {
> >>ret = -EPROBE_DEFER;
> >> - goto err_mipi_dsi_host;
> >> + goto err_unreg_mipi_dsi_host;
> >>}
> >>
> >>dev_set_drvdata(dev, dsi);
> >>pm_runtime_enable(dev);
> >>return 0;
> >>
> >> -err_mipi_dsi_host:
> >> +err_unreg_mipi_dsi_host:
> >>mipi_dsi_host_unregister(&dsi->dsi_host);
> >> -err_cleanup:
> >> - drm_encoder_cleanup(&dsi->encoder);
> >> - drm_connector_cleanup(&dsi->connector);
> >> -err_pllref:
> >> +err_disable_pm_runtime:
> >> + pm_runtime_disable(dev);
>
> I think that this is not required, 'pm_runtime_enable' is called just before
> the
> 'return 0' (see above). Commit 517f56839f58 'drm/rockchip: dw-mipi-dsi: fix
> possible un-balanced runtime PM enable' moved the call to that place. So, now
> the call to pm_runtime_disable is not needed.
>
> >> + dsi->connector.funcs->destroy(&dsi->connector);
> >> + dsi->encoder.funcs->destroy(&dsi->encoder);
>
> Here, there is a reordering and also a function replacement. The reorder makes
> sense to me, first cleanup the connector and then the encoder, but I'm not
> sure
> about the function change and if is needed, anyway, in the case is needed,
> shouldn't be
>
> + drm_connector_cleanup(&dsi->connector);
> + drm_encoder_cleanup(&dsi->encoder);
>
> instead?
If you look at drm/rockchip/dw-mipi-dsi.c you'll see that
dw_mipi_dsi_drm_connector_destroy() does both connector_unregister()
and drm_connector_cleanup().
And looking at other drivers it really seems that calling that destroy
callback is really the way to go.
Heiko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/4] drm/pl111: RealView and Versatile Express
On Fri, Mar 2, 2018 at 1:11 PM, Robin Murphy wrote: > On 02/03/18 09:09, Linus Walleij wrote: >> Also the Versatile Express CLCD on the motherboard has >> a dedicated video memory, and cannot use CMA (ha! complex!) >> and I will need to figure out a way to work around that. >> The CLCDs synthesized on the core tiles for CA9 work >> fine with this though. > > Out of curiosity, what's the issue with declaring the VRAM as a CMA region? > That's certainly worked for stuff like local RAM on FPGA tiles in the past, > and I can't think offhand of any way in which VExpress is wildly different > (but I am of course open to being wrong...) There is nothing wrong with that apart from my ignorance of that solution. So thanks! :D My experience with CMA is limited to using the 7 areas that are defined by default in Kconfig and the DRM helpers just plugging in on the front. Do you have some pointers? Is this something I can handily just set up in the device tree? Yours, Linus Walleij ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/8] drm: Add BT.2020 constant luminance enum value for the COLOR_ENCODING property
On Wed, Feb 14, 2018 at 09:23:21PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> BT.2020 specifies two YCbCr<->RGB conversion formulas. The more
> traditional non-constant luminance and a more complicate one constant
> luminance one. Add an enum value for the constant luminance variant
> as well in case someone has hardware supporting it.
>
> Cc: Harry Wentland
> Cc: Daniel Vetter
> Cc: Daniel Stone
> Cc: Russell King - ARM Linux
> Cc: Ilia Mirkin
> Cc: Hans Verkuil
> CC: Uma Shankar
> Cc: Shashank Sharma
> Cc: Jyri Sarha
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_color_mgmt.c | 1 +
> include/drm/drm_color_mgmt.h | 3 ++-
> 2 files changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_color_mgmt.c
> b/drivers/gpu/drm/drm_color_mgmt.c
> index a84fc861e406..061d342f9d96 100644
> --- a/drivers/gpu/drm/drm_color_mgmt.c
> +++ b/drivers/gpu/drm/drm_color_mgmt.c
> @@ -357,6 +357,7 @@ static const char * const color_encoding_name[] = {
> [DRM_COLOR_YCBCR_BT601] = "ITU-R BT.601 YCbCr",
> [DRM_COLOR_YCBCR_BT709] = "ITU-R BT.709 YCbCr",
> [DRM_COLOR_YCBCR_BT2020] = "ITU-R BT.2020 YCbCr",
> + [DRM_COLOR_YCBCR_BT2020_CONST] = "ITU-R BT.2020 YCbCr constant
> luminance",
I just realized that this exceeds the max prop enum name length
of 31 characters. I guess we'll just have to truncate it to something
like "ITU-R BT.2020 YCbCr const". Any better suggestions?
/me goes add some WARN_ON()s for invalid prop/enum names...
> };
>
> static const char * const color_range_name[] = {
> diff --git a/include/drm/drm_color_mgmt.h b/include/drm/drm_color_mgmt.h
> index b3b6d302ca8c..175943c87d5b 100644
> --- a/include/drm/drm_color_mgmt.h
> +++ b/include/drm/drm_color_mgmt.h
> @@ -41,7 +41,8 @@ int drm_mode_crtc_set_gamma_size(struct drm_crtc *crtc,
> enum drm_color_encoding {
> DRM_COLOR_YCBCR_BT601,
> DRM_COLOR_YCBCR_BT709,
> - DRM_COLOR_YCBCR_BT2020,
> + DRM_COLOR_YCBCR_BT2020, /* non-constant luminance */
> + DRM_COLOR_YCBCR_BT2020_CONST, /* constant luminance */
> DRM_COLOR_ENCODING_MAX,
> };
>
> --
> 2.13.6
--
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/8] drm: Add COLOR_ENCODING and COLOR_RANGE plane properties
On Wed, Feb 14, 2018 at 09:23:19PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > Here's a refresh of Jyri's COLOR_ENCODING and COLOR_RANGE properties, > and the i915 implementation I did on top. I tossed in a few core > updates as well: plane state dump, and the BT.2020 constant luminance > variant. > > Apparently nouveau is already exposing a "iturbt_709" bool property > which allows one to choose between BT.601 and BT.709 encodings, but > given that we want at least BT.2020 in addition I don't think that > property is good enough. Trying to implement it, and somehow extend > it beyond BT.601 vs. BT.709 seems like wasted effort. Hence I think > we should just ignore it and move on. > > My userspace implementation in the form of intel ddx > XV_COLORSPACE attribute: > https://patchwork.freedesktop.org/patch/204696/ > > Cc: Harry Wentland > Cc: Daniel Vetter > Cc: Daniel Stone > Cc: Russell King - ARM Linux > Cc: Ilia Mirkin > Cc: Hans Verkuil > Cc: Uma Shankar > Cc: Shashank Sharma > > Jyri Sarha (1): > drm: Add optional COLOR_ENCODING and COLOR_RANGE properties to > drm_plane > > Ville Syrjälä (7): > drm: Add BT.2020 constant luminance enum value for the COLOR_ENCODING > property > drm/atomic: Include color encoding/range in plane state dump > drm/i915: Correctly handle limited range YCbCr data on VLV/CHV > drm/i915: Fix plane YCbCr->RGB conversion for GLK > drm/i915: Add support for the YCbCr COLOR_ENCODING property > drm/i915: Change the COLOR_ENCODING prop default value to BT.709 > drm/i915: Add support for the YCbCr COLOR_RANGE property Userspace for i915 was deemed ready [1] so I've pushed the series (apart from the BT2020_CONST thing) to drm-misc-next. Thanks to everyone who worked on this. [1] https://lists.freedesktop.org/archives/intel-gfx/2018-March/157512.html -- Ville Syrjälä Intel OTC ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: omapdrm: displays: panel-dsi-cm: Fix field access before set
On 01/03/18 22:02, Laurent Pinchart wrote:
> The driver accesses the ddata->in field before it gets set in the
> dsicm_connect() function. Use the local in pointer variable instead.
>
> Fixes: 7877632b4cd0 ("drm: omapdrm: displays: Get panel source at connect
> time")
> Signed-off-by: Laurent Pinchart
> ---
> drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> Tomi,
>
> This patch fixes a bug in a commit from your omapdrm-next branch that
> hasn't been merged upstream yet. I'll let you decide whether you want to
> squash it with the offending commit (and thus rebase) or apply it on
> top. Sorry for screwing up :-/
Thanks, I've picked this up and applied on top of omapdrm-next.
Tomi
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/bridge/synopsys: dsi: readl_poll_timeout return value clean up
Hi Andrzej,
On 03/02/2018 11:21 AM, Andrzej Hajda wrote:
> On 01.03.2018 10:00, Philippe CORNU wrote:
>> Hi Archit, Andrzej & Laurent,
>>
>> May I ask you please your feedback on this small patch?
>> Many thanks,
>>
>> Philippe :-)
>>
>> On 02/04/2018 10:36 PM, Philippe Cornu wrote:
>>> The readl_poll_timeout() return value is 0 in case of success
>>> so it is better to detect errors without taking care of the
>>> return value sign.
>>>
>>> Signed-off-by: Philippe Cornu
>
> The patch is of course correct. However I am not sure if necessary. For
> sure functionally it does not change anything.
> AFAIK kernel CodingStyle says nothing about it, so I suppose it is
> matter of personal taste.
I sent this tiny patch in order to homogenize the dw mipi driver because
there were both cases "if (ret)" & "if (ret < 0)" in the source code.
I did not really find a preferred way in the kernel source code so I
selected what sounds the best to me ie "if (ret)" but it is not a
problem to make another patch for "if (ret < 0)" everywhere :-)
In any case, the most important from my pov is to have a homogeneous
source code :-)
Does anyone have a preferred choice between "if (ret)" & "if (ret < 0)"
after a "ret = readl_poll_timeout()"?
> Anyway I can give it:
> Reviewed-by: Andrzej Hajda
Many thanks,
Philippe :)
>
> --
> Regards
> Andrzej
>
>>> ---
>>>drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 10 +-
>>>1 file changed, 5 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
>>> b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
>>> index 65aeb3f78b48..4d0e8471a15c 100644
>>> --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
>>> +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
>>> @@ -342,7 +342,7 @@ static int dw_mipi_dsi_gen_pkt_hdr_write(struct
>>> dw_mipi_dsi *dsi, u32 hdr_val)
>>> ret = qq(dsi->base + DSI_CMD_PKT_STATUS,
>>> val, !(val & GEN_CMD_FULL), 1000,
>>> CMD_PKT_STATUS_TIMEOUT_US);
>>> - if (ret < 0) {
>>> + if (ret) {
>>> dev_err(dsi->dev, "failed to get available command FIFO\n");
>>> return ret;
>>> }
>>> @@ -353,7 +353,7 @@ static int dw_mipi_dsi_gen_pkt_hdr_write(struct
>>> dw_mipi_dsi *dsi, u32 hdr_val)
>>> ret = readl_poll_timeout(dsi->base + DSI_CMD_PKT_STATUS,
>>> val, (val & mask) == mask,
>>> 1000, CMD_PKT_STATUS_TIMEOUT_US);
>>> - if (ret < 0) {
>>> + if (ret) {
>>> dev_err(dsi->dev, "failed to write command FIFO\n");
>>> return ret;
>>> }
>>> @@ -385,7 +385,7 @@ static int dw_mipi_dsi_write(struct dw_mipi_dsi *dsi,
>>> ret = readl_poll_timeout(dsi->base + DSI_CMD_PKT_STATUS,
>>> val, !(val & GEN_PLD_W_FULL), 1000,
>>> CMD_PKT_STATUS_TIMEOUT_US);
>>> - if (ret < 0) {
>>> + if (ret) {
>>> dev_err(dsi->dev,
>>> "failed to get available write payload FIFO\n");
>>> return ret;
>>> @@ -716,13 +716,13 @@ static void dw_mipi_dsi_dphy_enable(struct
>>> dw_mipi_dsi *dsi)
>>>
>>> ret = readl_poll_timeout(dsi->base + DSI_PHY_STATUS, val,
>>> val & PHY_LOCK, 1000, PHY_STATUS_TIMEOUT_US);
>>> - if (ret < 0)
>>> + if (ret)
>>> DRM_DEBUG_DRIVER("failed to wait phy lock state\n");
>>>
>>> ret = readl_poll_timeout(dsi->base + DSI_PHY_STATUS,
>>> val, val & PHY_STOP_STATE_CLK_LANE, 1000,
>>> PHY_STATUS_TIMEOUT_US);
>>> - if (ret < 0)
>>> + if (ret)
>>> DRM_DEBUG_DRIVER("failed to wait phy clk lane stop state\n");
>>>}
>>>
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] drm: Don't create properties without names
From: Ville Syrjälä
Creating a property that doesn't have a name makes no sense to me. Don't
allow it.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_property.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_property.c b/drivers/gpu/drm/drm_property.c
index bae50e6b819d..fe8627fb7ae6 100644
--- a/drivers/gpu/drm/drm_property.c
+++ b/drivers/gpu/drm/drm_property.c
@@ -99,10 +99,8 @@ struct drm_property *drm_property_create(struct drm_device
*dev, int flags,
property->num_values = num_values;
INIT_LIST_HEAD(&property->enum_list);
- if (name) {
- strncpy(property->name, name, DRM_PROP_NAME_LEN);
- property->name[DRM_PROP_NAME_LEN-1] = '\0';
- }
+ strncpy(property->name, name, DRM_PROP_NAME_LEN);
+ property->name[DRM_PROP_NAME_LEN-1] = '\0';
list_add_tail(&property->head, &dev->mode_config.property_list);
--
2.13.6
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/3] drm: Add BT.2020 constant luminance enum value for the COLOR_ENCODING property
From: Ville Syrjälä
BT.2020 specifies two YCbCr<->RGB conversion formulas. The more
traditional non-constant luminance and a more complicate constant
luminance one. Add an enum value for the constant luminance variant
as well in case someone has hardware supporting it.
v2: Reduce the enum name to fit within the 31 character uapi limit
Cc: Harry Wentland
Cc: Daniel Vetter
Cc: Daniel Stone
Cc: Russell King - ARM Linux
Cc: Ilia Mirkin
Cc: Hans Verkuil
CC: Uma Shankar
Cc: Shashank Sharma
Cc: Jyri Sarha
Signed-off-by: Ville Syrjälä
Acked-by: Harry Wentland #v1
---
drivers/gpu/drm/drm_color_mgmt.c | 1 +
include/drm/drm_color_mgmt.h | 3 ++-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_color_mgmt.c b/drivers/gpu/drm/drm_color_mgmt.c
index 4ff064623836..cc28c32399af 100644
--- a/drivers/gpu/drm/drm_color_mgmt.c
+++ b/drivers/gpu/drm/drm_color_mgmt.c
@@ -358,6 +358,7 @@ static const char * const color_encoding_name[] = {
[DRM_COLOR_YCBCR_BT601] = "ITU-R BT.601 YCbCr",
[DRM_COLOR_YCBCR_BT709] = "ITU-R BT.709 YCbCr",
[DRM_COLOR_YCBCR_BT2020] = "ITU-R BT.2020 YCbCr",
+ [DRM_COLOR_YCBCR_BT2020_CONST] = "ITU-R BT.2020 YCbCr const",
};
static const char * const color_range_name[] = {
diff --git a/include/drm/drm_color_mgmt.h b/include/drm/drm_color_mgmt.h
index b3b6d302ca8c..175943c87d5b 100644
--- a/include/drm/drm_color_mgmt.h
+++ b/include/drm/drm_color_mgmt.h
@@ -41,7 +41,8 @@ int drm_mode_crtc_set_gamma_size(struct drm_crtc *crtc,
enum drm_color_encoding {
DRM_COLOR_YCBCR_BT601,
DRM_COLOR_YCBCR_BT709,
- DRM_COLOR_YCBCR_BT2020,
+ DRM_COLOR_YCBCR_BT2020, /* non-constant luminance */
+ DRM_COLOR_YCBCR_BT2020_CONST, /* constant luminance */
DRM_COLOR_ENCODING_MAX,
};
--
2.13.6
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/3] drm: Check property/enum name length
From: Ville Syrjälä
Reject requests to add properties/enums with an overly long name.
Previously we would have just silently truncated the string and exposed
it userspace.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_property.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/drm_property.c b/drivers/gpu/drm/drm_property.c
index fe8627fb7ae6..f062adf21b9c 100644
--- a/drivers/gpu/drm/drm_property.c
+++ b/drivers/gpu/drm/drm_property.c
@@ -78,6 +78,9 @@ struct drm_property *drm_property_create(struct drm_device
*dev, int flags,
struct drm_property *property = NULL;
int ret;
+ if (WARN_ON(strlen(name) >= DRM_PROP_NAME_LEN))
+ return -EINVAL;
+
property = kzalloc(sizeof(struct drm_property), GFP_KERNEL);
if (!property)
return NULL;
@@ -372,6 +375,9 @@ int drm_property_add_enum(struct drm_property *property,
int index,
{
struct drm_property_enum *prop_enum;
+ if (WARN_ON(strlen(name) >= DRM_PROP_NAME_LEN))
+ return -EINVAL;
+
if (!(drm_property_type_is(property, DRM_MODE_PROP_ENUM) ||
drm_property_type_is(property, DRM_MODE_PROP_BITMASK)))
return -EINVAL;
--
2.13.6
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/bridge: sii902x: Fall back to standard modes
On Fri, Mar 2, 2018 at 9:07 AM, Ville Syrjälä wrote: > On Thu, Mar 01, 2018 at 11:12:15PM +0100, Linus Walleij wrote: >> On Thu, Mar 1, 2018 at 10:18 PM, Ville Syrjälä >> wrote: >> > On Thu, Mar 01, 2018 at 10:02:55PM +0100, Linus Walleij wrote: >> >> Hm, hard to get review feedback on this one. >> >> >> >> It gives me proper video on an ARM Versatile Express utilizing the >> >> bridge driver with a plugged in DVI-to-VGA dongle with the new >> >> PL111 DRI driver. >> >> >> >> Liviu? Pawel? >> >> >> >> Some ACK is fine to know I am doing the right thing :) >> > >> > Why isn't the probe helper's noedid fallback working? >> >> Where is that in the call chain? >> >> The problem I have is that the bridge is there, it gets properly >> initialized and used as connector and all. The only problem is >> that the DDI I2C portion of it is not working, so no modes are >> really added from the struct drm_connector_helper_funcs >> .get_modes() callback. > > The helper is what calls .get_modes(), and it has a noedid > fallback for mode count==0. OK I'll debug from here and try to see what's wrong. Yours, Linus Walleij ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 105300] amd-staging-drm-next-git 4.16 & RX 560 DL-DVI: corruption with refreshrates >73Hz when DPM changing VRAM clock
https://bugs.freedesktop.org/show_bug.cgi?id=105300 --- Comment #5 from tempel.jul...@gmail.com --- Created attachment 137752 --> https://bugs.freedesktop.org/attachment.cgi?id=137752&action=edit dmesg.log -- 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 105300] amd-staging-drm-next-git 4.16 & RX 560 DL-DVI: corruption with refreshrates >73Hz when DPM changing VRAM clock
https://bugs.freedesktop.org/show_bug.cgi?id=105300 --- Comment #6 from tempel.jul...@gmail.com --- Created attachment 137753 --> https://bugs.freedesktop.org/attachment.cgi?id=137753&action=edit Xorg.0.log -- 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 105300] amd-staging-drm-next-git 4.16 & RX 560 DL-DVI: corruption with refreshrates >73Hz when DPM changing VRAM clock
https://bugs.freedesktop.org/show_bug.cgi?id=105300 --- Comment #7 from tempel.jul...@gmail.com --- Created attachment 137754 --> https://bugs.freedesktop.org/attachment.cgi?id=137754&action=edit xrandr.log -- 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 105300] amd-staging-drm-next-git 4.16 & RX 560 DL-DVI: corruption with refreshrates >73Hz when DPM changing VRAM clock
https://bugs.freedesktop.org/show_bug.cgi?id=105300 --- Comment #8 from tempel.jul...@gmail.com --- Video which shows the artifacts: https://youtu.be/it3d6BjpZjU (can also be quite worse when doing stuff) It happens with every desktop environment with and without enabled OGL compositor. In the video, it's KDE Plasma on Xorg. But there is no difference with a Wayland session, the artifacts there are the same. You are correct that the display's own edid information doesn't know any other refreshrate than 59.95Hz. However, these Korean import display's are very often used with higher refreshrates because their panels allow this without incompatible scaler in between. With the old display stack, I can even set 85Hz without any issues. 75Hz is also not very uncommon for some 2560x1440p IPS displays, I suppose there is the realistic possibility that also displays which have a 2560x1440 75Hz resolution in their original edid are affected by this bug (since the old stack isn't affected, I'm quite sure it's some kind of bug). -- 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 1/4] dt-bindings: display/ti: Move common dispc bindings to omap-dss.txt
Add common DISPC bindings into the top level bindings file. Move common bindings here instead of having multiple copies of the same information in all of the variant specific files. Signed-off-by: Benoit Parrot --- Documentation/devicetree/bindings/display/ti/ti,dra7-dss.txt | 5 - Documentation/devicetree/bindings/display/ti/ti,omap-dss.txt | 7 +++ Documentation/devicetree/bindings/display/ti/ti,omap2-dss.txt | 4 Documentation/devicetree/bindings/display/ti/ti,omap3-dss.txt | 4 Documentation/devicetree/bindings/display/ti/ti,omap4-dss.txt | 4 Documentation/devicetree/bindings/display/ti/ti,omap5-dss.txt | 4 6 files changed, 7 insertions(+), 21 deletions(-) diff --git a/Documentation/devicetree/bindings/display/ti/ti,dra7-dss.txt b/Documentation/devicetree/bindings/display/ti/ti,dra7-dss.txt index 91279f1060fe..c30f9ec189ed 100644 --- a/Documentation/devicetree/bindings/display/ti/ti,dra7-dss.txt +++ b/Documentation/devicetree/bindings/display/ti/ti,dra7-dss.txt @@ -47,11 +47,6 @@ Required properties: - clocks: handle to fclk - clock-names: "fck" -Optional properties: -- max-memory-bandwidth: Input memory (from main memory to dispc) bandwidth limit - in bytes per second - - HDMI diff --git a/Documentation/devicetree/bindings/display/ti/ti,omap-dss.txt b/Documentation/devicetree/bindings/display/ti/ti,omap-dss.txt index e1ef29569338..249e588d7865 100644 --- a/Documentation/devicetree/bindings/display/ti/ti,omap-dss.txt +++ b/Documentation/devicetree/bindings/display/ti/ti,omap-dss.txt @@ -21,6 +21,13 @@ a RGB pixel stream to encoders. The encoder modules encode the received RGB pixel stream to a video output like HDMI, MIPI DPI, etc. +DISPC +- + +Optional properties: +- max-memory-bandwidth: Input memory (from main memory to dispc) bandwidth limit + in bytes per second + Video Ports --- diff --git a/Documentation/devicetree/bindings/display/ti/ti,omap2-dss.txt b/Documentation/devicetree/bindings/display/ti/ti,omap2-dss.txt index ee867c4d1152..afcd5a86c6a4 100644 --- a/Documentation/devicetree/bindings/display/ti/ti,omap2-dss.txt +++ b/Documentation/devicetree/bindings/display/ti/ti,omap2-dss.txt @@ -28,10 +28,6 @@ Required properties: - ti,hwmods: "dss_dispc" - interrupts: the DISPC interrupt -Optional properties: -- max-memory-bandwidth: Input memory (from main memory to dispc) bandwidth limit - in bytes per second - RFBI diff --git a/Documentation/devicetree/bindings/display/ti/ti,omap3-dss.txt b/Documentation/devicetree/bindings/display/ti/ti,omap3-dss.txt index cd02516a40b6..dc66e1447c31 100644 --- a/Documentation/devicetree/bindings/display/ti/ti,omap3-dss.txt +++ b/Documentation/devicetree/bindings/display/ti/ti,omap3-dss.txt @@ -37,10 +37,6 @@ Required properties: - clocks: handle to fclk - clock-names: "fck" -Optional properties: -- max-memory-bandwidth: Input memory (from main memory to dispc) bandwidth limit - in bytes per second - RFBI diff --git a/Documentation/devicetree/bindings/display/ti/ti,omap4-dss.txt b/Documentation/devicetree/bindings/display/ti/ti,omap4-dss.txt index 0f85f6b3a5a8..bc624dbd 100644 --- a/Documentation/devicetree/bindings/display/ti/ti,omap4-dss.txt +++ b/Documentation/devicetree/bindings/display/ti/ti,omap4-dss.txt @@ -36,10 +36,6 @@ Required properties: - clocks: handle to fclk - clock-names: "fck" -Optional properties: -- max-memory-bandwidth: Input memory (from main memory to dispc) bandwidth limit - in bytes per second - RFBI diff --git a/Documentation/devicetree/bindings/display/ti/ti,omap5-dss.txt b/Documentation/devicetree/bindings/display/ti/ti,omap5-dss.txt index 20861218649f..118a486c47bb 100644 --- a/Documentation/devicetree/bindings/display/ti/ti,omap5-dss.txt +++ b/Documentation/devicetree/bindings/display/ti/ti,omap5-dss.txt @@ -36,10 +36,6 @@ Required properties: - clocks: handle to fclk - clock-names: "fck" -Optional properties: -- max-memory-bandwidth: Input memory (from main memory to dispc) bandwidth limit - in bytes per second - RFBI -- 2.9.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/4] drm/pl111: RealView and Versatile Express
On 02/03/18 12:37, Linus Walleij wrote:
On Fri, Mar 2, 2018 at 1:11 PM, Robin Murphy wrote:
On 02/03/18 09:09, Linus Walleij wrote:
Also the Versatile Express CLCD on the motherboard has
a dedicated video memory, and cannot use CMA (ha! complex!)
and I will need to figure out a way to work around that.
The CLCDs synthesized on the core tiles for CA9 work
fine with this though.
Out of curiosity, what's the issue with declaring the VRAM as a CMA region?
That's certainly worked for stuff like local RAM on FPGA tiles in the past,
and I can't think offhand of any way in which VExpress is wildly different
(but I am of course open to being wrong...)
There is nothing wrong with that apart from my ignorance
of that solution. So thanks! :D
My experience with CMA is limited to using the 7 areas
that are defined by default in Kconfig and the DRM helpers
just plugging in on the front.
Do you have some pointers? Is this something I can
handily just set up in the device tree?
It should be - the inner workings of dma-{coherent,contiguous} are a
maze of twisty little passages, all alike, and it'll take me a while to
page the details back in, but IIRC it's mostly just a case of having a
reserved-memory node covering the VRAM with the right combination of
magic properties for rmem_dma_setup() to pick up, such that it gets
assigned as the CLCD's private region. The subsequent "just plugging in"
aspect doesn't change, it just makes allocations start taking this route
under the covers:
drm_gem_cma_create()
dma_alloc_wc()
dma_alloc_attrs()
dma_alloc_from_dev_coherent()
I could have sworn I've exchanged relevant FPGA DT fragments with Liviu
in the past, but now I can't seem to find one to refer back to :(
Robin.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/3 drm: Check property/enum name length
From: Ville Syrjälä
Reject requests to add properties/enums with an overly long name.
Previously we would have just silently truncated the string and exposed
it userspace.
v2: drm_property_create() returns a pointer
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_property.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/drm_property.c b/drivers/gpu/drm/drm_property.c
index fe8627fb7ae6..c37ac41125b5 100644
--- a/drivers/gpu/drm/drm_property.c
+++ b/drivers/gpu/drm/drm_property.c
@@ -78,6 +78,9 @@ struct drm_property *drm_property_create(struct drm_device
*dev, int flags,
struct drm_property *property = NULL;
int ret;
+ if (WARN_ON(strlen(name) >= DRM_PROP_NAME_LEN))
+ return NULL;
+
property = kzalloc(sizeof(struct drm_property), GFP_KERNEL);
if (!property)
return NULL;
@@ -372,6 +375,9 @@ int drm_property_add_enum(struct drm_property *property,
int index,
{
struct drm_property_enum *prop_enum;
+ if (WARN_ON(strlen(name) >= DRM_PROP_NAME_LEN))
+ return -EINVAL;
+
if (!(drm_property_type_is(property, DRM_MODE_PROP_ENUM) ||
drm_property_type_is(property, DRM_MODE_PROP_BITMASK)))
return -EINVAL;
--
2.16.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Patch 0/4] drm/omap: Add virtual-planes support
This patch series adds virtual-plane support to omapdrm driver to allow the use of display wider than 2048 pixels. The DT bindings are also cleaned up to remove duplication when properties are common to all implementations. Benoit Parrot (4): dt-bindings: display/ti: Move common dispc bindings to omap-dss.txt dt-bindings: display/ti: Add plane binding to dispc node drm/omap: Add virtual plane DT parsing support drm/omap: Add virtual plane support to omap_plane .../devicetree/bindings/display/ti/ti,dra7-dss.txt | 5 - .../devicetree/bindings/display/ti/ti,omap-dss.txt | 70 +++ .../bindings/display/ti/ti,omap2-dss.txt | 4 - .../bindings/display/ti/ti,omap3-dss.txt | 4 - .../bindings/display/ti/ti,omap4-dss.txt | 4 - .../bindings/display/ti/ti,omap5-dss.txt | 4 - drivers/gpu/drm/omapdrm/dss/dispc.c| 110 drivers/gpu/drm/omapdrm/dss/omapdss.h | 11 ++ drivers/gpu/drm/omapdrm/omap_drv.c | 18 ++- drivers/gpu/drm/omapdrm/omap_fb.c | 66 ++ drivers/gpu/drm/omapdrm/omap_fb.h | 4 +- drivers/gpu/drm/omapdrm/omap_plane.c | 139 +++-- drivers/gpu/drm/omapdrm/omap_plane.h | 3 +- 13 files changed, 353 insertions(+), 89 deletions(-) -- 2.9.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Patch 3/4] drm/omap: Add virtual plane DT parsing support
Virtual planes are used to extend display size capability for display
larger than 2048 pixels by splitting the frame buffer equally between
two physical planes.
Here we are adding DT support to parse 'plane' child nodes which
describe how logical planes are mapped to physical plane(s) and
which crtc they are available on.
Signed-off-by: Benoit Parrot
---
drivers/gpu/drm/omapdrm/dss/dispc.c | 110 ++
drivers/gpu/drm/omapdrm/dss/omapdss.h | 11
2 files changed, 121 insertions(+)
diff --git a/drivers/gpu/drm/omapdrm/dss/dispc.c
b/drivers/gpu/drm/omapdrm/dss/dispc.c
index 624dee22f46b..559b70d9762d 100644
--- a/drivers/gpu/drm/omapdrm/dss/dispc.c
+++ b/drivers/gpu/drm/omapdrm/dss/dispc.c
@@ -4334,6 +4334,115 @@ static u32 dispc_get_memory_bandwidth_limit(void)
return limit;
}
+static struct device_node *dispc_of_get_plane_by_id(struct device_node *node,
+ u32 id)
+{
+ struct device_node *plane;
+
+ for_each_child_of_node(node, plane) {
+ u32 plane_id = 0;
+
+ if (of_node_cmp(plane->name, "plane") != 0)
+ continue;
+ of_property_read_u32(plane, "reg", &plane_id);
+ if (id == plane_id)
+ break;
+ }
+
+ return plane;
+}
+
+static int dispc_parse_dt_plane_data(struct dispc_plane_mappings *plane)
+{
+ struct platform_device *pdev = dispc.pdev;
+ struct device_node *np = pdev->dev.of_node;
+ struct device_node *ep;
+ struct property *prop;
+ const __be32 *cur;
+ u32 v;
+ u32 num_ovls = dispc_get_num_ovls();
+ unsigned long int hw_plane_mask = (1 << num_ovls) - 1;
+ u32 num_planes;
+ int i, index;
+
+ if (!np)
+ return 0;
+
+ for (i = 0; i < num_ovls; i++) {
+ ep = dispc_of_get_plane_by_id(np, i);
+ if (!ep)
+ break;
+ if (!of_property_read_bool(ep, "hw-planes")) {
+ dev_err(&pdev->dev,
+ "malformed plane node: hw-planes missing.\n");
+ return -EINVAL;
+ }
+
+ index = 0;
+ of_property_for_each_u32(ep, "hw-planes", prop, cur, v) {
+ if (v >= num_ovls) {
+ dev_err(&pdev->dev,
+ "hw-planes property: '%d'
out-of-range.\n",
+ v);
+ return -EINVAL;
+ }
+ if (!(hw_plane_mask & BIT_MASK(v))) {
+ dev_err(&pdev->dev,
+ "hw-planes property: '%d' used more
than once.\n",
+ v);
+ return -EINVAL;
+ }
+ clear_bit(v, &hw_plane_mask);
+
+ if (index == 0) {
+ plane->plane[i].main_id = v;
+ } else if (index == 1) {
+ plane->plane[i].aux_id = v;
+ plane->plane[i].is_virtual = true;
+ } else if (index > 1) {
+ dev_err(&pdev->dev,
+ "hw-planes property: more than 2 values
specified.\n");
+ return -EINVAL;
+ }
+ index++;
+ }
+
+ of_property_for_each_u32(ep, "hw-crtcs", prop, cur, v) {
+ if (v >= num_ovls) {
+ dev_err(&pdev->dev,
+ "hw-crtcs property: '%d'
out-of-range.\n",
+ v);
+ return -EINVAL;
+ }
+ plane->plane[i].crtc_mask |= 1 << v;
+ }
+ }
+
+ num_planes = i;
+
+ if (num_planes) {
+ dev_dbg(&pdev->dev, "Plane definitions found from DT:");
+ for (i = 0; i < num_planes; i++) {
+ if (plane->plane[i].is_virtual) {
+ dev_dbg(&pdev->dev,
+ "plane%d: virtual hw-planes: %d, %d
crtc_mask: 0x%04x",
+ i, plane->plane[i].main_id,
+ plane->plane[i].aux_id,
+ plane->plane[i].crtc_mask);
+ } else {
+ dev_dbg(&pdev->dev,
+ "plane%d: hw-planes: %d crtc_mask:
0x%04x",
+ i, plane->plane[i].main_id,
+ plane->plane[i].crtc_mask);
+
Re: [RFC PATCH hwc] drm_hwcomposer: set CRTC background color when available
Ack, thanks for the heads up! Rob. On 03/02/2018 01:41 AM, Stefan Schake wrote: Hey Rob, On Wed, Feb 28, 2018 at 11:53 AM, Robert Foss wrote: Hey, Stefan: Are you looking at an entirely kernel side fix now, or are you pushing this series forward? I've sent out a kernel side fix for this: https://patchwork.freedesktop.org/patch/207667/ So I guess for now this can be dropped, pending review. Thanks, Stefan ___ 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: [PATCH 2/2] drm/sun4i: add lvds mode_valid function
On Fri, Mar 02, 2018 at 12:42:14PM +0100, Giulio Benetti wrote:
> Hi,
>
> Il 01/03/2018 10:57, Maxime Ripard ha scritto:
> > On Wed, Feb 28, 2018 at 06:53:52PM +0100, Giulio Benetti wrote:
> > > static struct drm_connector_helper_funcs sun4i_lvds_con_helper_funcs = {
> > > .get_modes = sun4i_lvds_get_modes,
> > > + .mode_valid = sun4i_lvds_mode_valid,
> > > };
> >
> > This should be on the encoder, not the connector.
>
> I've seen it is bound to connector in rgb and to encoder in hdmi.
> Is it correct rgb mode_valid under connector funcs?
> Otherwise I send a patch also for that one.
This would need to be fixed as well. Bridges attach to encoder, not
connectors, so if you ever have a bridge connected to the RGB output
(like on the A13-Olinuxino), mode_valid isn't called at the moment.
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/vc4: Ignore alpha on primary plane
On Fri, Mar 02, 2018 at 01:32:40AM +0100, Stefan Schake wrote: > We allow alpha formats on the primary plane but a partially transparent > framebuffer will cause a corrupted display. With this change black pixels > are output instead, in line with the behavior for other DRM drivers. > > Signed-off-by: Stefan Schake > --- > Test program is available at https://github.com/stschake/vc4-alpha-test > > drivers/gpu/drm/vc4/vc4_plane.c | 7 ++- > 1 file changed, 6 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c > index 61ad955..8c829fa 100644 > --- a/drivers/gpu/drm/vc4/vc4_plane.c > +++ b/drivers/gpu/drm/vc4/vc4_plane.c > @@ -521,6 +521,7 @@ static int vc4_plane_mode_set(struct drm_plane *plane, > u32 ctl0_offset = vc4_state->dlist_count; > const struct hvs_format *format = > vc4_get_hvs_format(fb->format->format); > int num_planes = drm_format_num_planes(format->drm); > + bool primary_plane = state->crtc->primary == plane; > u32 scl0, scl1, pitch0; > u32 lbm_size, tiling; > unsigned long irqflags; > @@ -620,8 +621,12 @@ static int vc4_plane_mode_set(struct drm_plane *plane, > > /* Position Word 2: Source Image Size, Alpha Mode */ > vc4_state->pos2_offset = vc4_state->dlist_count; > + /* We do not enable the HVS background color fill so the primary plane > + * must be opaque to avoid display artifacts. Achieve this by always > + * using fixed alpha (initialized to 0xff above) on the primary plane. > + */ > vc4_dlist_write(vc4_state, > - VC4_SET_FIELD(fb->format->has_alpha ? > + VC4_SET_FIELD(fb->format->has_alpha && !primary_plane ? If you want the plane to always be opaque you shouldn't expose any formats with alpha. Also what happens if one disables the primary plane? Or does the driver not allow that? > SCALER_POS2_ALPHA_MODE_PIPELINE : > SCALER_POS2_ALPHA_MODE_FIXED, > SCALER_POS2_ALPHA_MODE) | > -- > 2.7.4 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Ville Syrjälä Intel OTC ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/vc4: Ignore alpha on primary plane
On Fri, Mar 02, 2018 at 04:39:22PM +0200, Ville Syrjälä wrote: > On Fri, Mar 02, 2018 at 01:32:40AM +0100, Stefan Schake wrote: > > We allow alpha formats on the primary plane but a partially transparent > > framebuffer will cause a corrupted display. With this change black pixels > > are output instead, in line with the behavior for other DRM drivers. > > > > Signed-off-by: Stefan Schake > > --- > > Test program is available at https://github.com/stschake/vc4-alpha-test > > > > drivers/gpu/drm/vc4/vc4_plane.c | 7 ++- > > 1 file changed, 6 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/vc4/vc4_plane.c > > b/drivers/gpu/drm/vc4/vc4_plane.c > > index 61ad955..8c829fa 100644 > > --- a/drivers/gpu/drm/vc4/vc4_plane.c > > +++ b/drivers/gpu/drm/vc4/vc4_plane.c > > @@ -521,6 +521,7 @@ static int vc4_plane_mode_set(struct drm_plane *plane, > > u32 ctl0_offset = vc4_state->dlist_count; > > const struct hvs_format *format = > > vc4_get_hvs_format(fb->format->format); > > int num_planes = drm_format_num_planes(format->drm); > > + bool primary_plane = state->crtc->primary == plane; > > u32 scl0, scl1, pitch0; > > u32 lbm_size, tiling; > > unsigned long irqflags; > > @@ -620,8 +621,12 @@ static int vc4_plane_mode_set(struct drm_plane *plane, > > > > /* Position Word 2: Source Image Size, Alpha Mode */ > > vc4_state->pos2_offset = vc4_state->dlist_count; > > + /* We do not enable the HVS background color fill so the primary plane > > +* must be opaque to avoid display artifacts. Achieve this by always > > +* using fixed alpha (initialized to 0xff above) on the primary plane. > > +*/ > > vc4_dlist_write(vc4_state, > > - VC4_SET_FIELD(fb->format->has_alpha ? > > + VC4_SET_FIELD(fb->format->has_alpha && !primary_plane ? > > If you want the plane to always be opaque you shouldn't expose any > formats with alpha. > > Also what happens if one disables the primary plane? Or does the driver > not allow that? Or just makes the plane not cover the entire screen? -- Ville Syrjälä Intel OTC ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 01/14] iommu: Add DOMAIN_ATTR_ENABLE_TTBR1
On 21/02/18 22:59, Jordan Crouse wrote:
Add a new domain attribute to enable the TTBR1 pagetable for drivers
and devices that support it. This will enabled using a TTBR1 (otherwise
known as a "global" or "system" pagetable for devices that support a split
pagetable scheme for switching pagetables quickly and safely.
TTBR1 is very much an Arm VMSA-specific term; if the concept of a split
address space is useful in general, is it worth trying to frame it in
general terms? AFAICS other IOMMU drivers could achieve the same effect
fairly straightforwardly by simply copying the top-level "global"
entries across whenever they switch "private" tables.
FWIW even for SMMU there could potentially be cases with Arm Ltd. IP
where the SoC vendor implements a stage-2-only configuration in their
media subsystem, because they care most about minimising area and
stage-1-only isn't an option.
Robin.
Signed-off-by: Jordan Crouse
---
include/linux/iommu.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index 641aaf0f1b81..e2c49e583d8d 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -153,6 +153,7 @@ enum iommu_attr {
DOMAIN_ATTR_FSL_PAMU_ENABLE,
DOMAIN_ATTR_FSL_PAMUV1,
DOMAIN_ATTR_NESTING,/* two stages of translation */
+ DOMAIN_ATTR_ENABLE_TTBR1,
DOMAIN_ATTR_MAX,
};
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [DPU PATCH 06/11] drm/msm: Remove msm_commit/kthread, use atomic helper commit
On Thu, Mar 01, 2018 at 07:37:10PM -0500, Rob Clark wrote:
> On Thu, Mar 1, 2018 at 3:37 PM, wrote:
> > On 2018-03-01 07:27, Sean Paul wrote:
> >>
> >> On Wed, Feb 28, 2018 at 08:07:00PM -0800, jsa...@codeaurora.org wrote:
> >>>
> >>> On 2018-02-28 11:19, Sean Paul wrote:
> >>> > Moving further towards switching fully to the the atomic helpers, this
> >>> > patch removes the hand-rolled kthread nonblock commit code and uses
> >>
> >> the
> >>>
> >>> > atomic helpers commit_work model.
> >>> >
> >>> > There's still a lot of copypasta here, but it's still needed to
> >>> > facilitate the swap_state and prepare_fence private functions. These
> >>> > will be sorted out in a follow-on patch.
> >>> >
> >>> > Change-Id: I9fcba27824ba63d3fab96cb2bc194bfa6f3475b7
> >>> > Signed-off-by: Sean Paul
> >>> > ---
> >>> > drivers/gpu/drm/msm/msm_atomic.c | 199
> >>
> >> ++-
> >>>
> >>> > drivers/gpu/drm/msm/msm_drv.c| 1 -
> >>> > drivers/gpu/drm/msm/msm_drv.h| 4 -
> >>> > 3 files changed, 35 insertions(+), 169 deletions(-)
> >>> >
> >>> > diff --git a/drivers/gpu/drm/msm/msm_atomic.c
> >>> > b/drivers/gpu/drm/msm/msm_atomic.c
> >>> > index 3a18bd3dc215..7e54eb65d096 100644
> >>> > --- a/drivers/gpu/drm/msm/msm_atomic.c
> >>> > +++ b/drivers/gpu/drm/msm/msm_atomic.c
> >>> > @@ -21,51 +21,6 @@
> >>> > #include "msm_gem.h"
> >>> > #include "msm_fence.h"
> >>> >
> >>> > -struct msm_commit {
> >>> > - struct drm_device *dev;
> >>> > - struct drm_atomic_state *state;
> >>> > - uint32_t crtc_mask;
> >>> > - bool nonblock;
> >>> > - struct kthread_work commit_work;
> >>> > -};
> >>> > -
> >>> > -/* block until specified crtcs are no longer pending update, and
> >>> > - * atomically mark them as pending update
> >>> > - */
> >>> > -static int start_atomic(struct msm_drm_private *priv, uint32_t
> >>> > crtc_mask)
> >>> > -{
> >>> > - int ret;
> >>> > -
> >>> > - spin_lock(&priv->pending_crtcs_event.lock);
> >>> > - ret = wait_event_interruptible_locked(priv->pending_crtcs_event,
> >>> > - !(priv->pending_crtcs & crtc_mask));
> >>> > - if (ret == 0) {
> >>> > - DBG("start: %08x", crtc_mask);
> >>> > - priv->pending_crtcs |= crtc_mask;
> >>> > - }
> >>> > - spin_unlock(&priv->pending_crtcs_event.lock);
> >>> > -
> >>> > - return ret;
> >>> > -}
> >>> > -
> >>> > -/* clear specified crtcs (no longer pending update)
> >>> > - */
> >>> > -static void end_atomic(struct msm_drm_private *priv, uint32_t
> >>> > crtc_mask)
> >>> > -{
> >>> > - spin_lock(&priv->pending_crtcs_event.lock);
> >>> > - DBG("end: %08x", crtc_mask);
> >>> > - priv->pending_crtcs &= ~crtc_mask;
> >>> > - wake_up_all_locked(&priv->pending_crtcs_event);
> >>> > - spin_unlock(&priv->pending_crtcs_event.lock);
> >>> > -}
> >>> > -
> >>> > -static void commit_destroy(struct msm_commit *c)
> >>> > -{
> >>> > - end_atomic(c->dev->dev_private, c->crtc_mask);
> >>> > - if (c->nonblock)
> >>> > - kfree(c);
> >>> > -}
> >>> > -
> >>> > static void msm_atomic_wait_for_commit_done(
> >>> > struct drm_device *dev,
> >>> > struct drm_atomic_state *old_state)
> >>> > @@ -118,6 +73,10 @@ static void msm_atomic_commit_tail(struct
> >>> > drm_atomic_state *state)
> >>> >
> >>> > msm_atomic_wait_for_commit_done(dev, state);
> >>> >
> >>> > + drm_atomic_helper_commit_hw_done(state);
> >>> > +
> >>> > + drm_atomic_helper_wait_for_vblanks(dev, state);
> >>> > +
> >>> > drm_atomic_helper_cleanup_planes(dev, state);
> >>> >
> >>> > kms->funcs->complete_commit(kms, state);
> >>> > @@ -126,109 +85,25 @@ static void msm_atomic_commit_tail(struct
> >>> > drm_atomic_state *state)
> >>> > /* The (potentially) asynchronous part of the commit. At this point
> >>> > * nothing can fail short of armageddon.
> >>> > */
> >>> > -static void complete_commit(struct msm_commit *c)
> >>> > +static void commit_tail(struct drm_atomic_state *state)
> >>> > {
> >>> > - struct drm_atomic_state *state = c->state;
> >>> > - struct drm_device *dev = state->dev;
> >>> > + drm_atomic_helper_wait_for_fences(state->dev, state, false);
> >>> >
> >>> > - drm_atomic_helper_wait_for_fences(dev, state, false);
> >>> > + drm_atomic_helper_wait_for_dependencies(state);
> >>> >
> >>> > msm_atomic_commit_tail(state);
> >>> >
> >>> > - drm_atomic_state_put(state);
> >>> > -}
> >>> > -
> >>> > -static void _msm_drm_commit_work_cb(struct kthread_work *work)
> >>> > -{
> >>> > - struct msm_commit *commit = NULL;
> >>> > -
> >>> > - if (!work) {
> >>> > - DRM_ERROR("%s: Invalid commit work data!\n", __func__);
> >>> > - return;
> >>> > - }
> >>> > -
> >>> > - commit = container_of(work, struct msm_commit, commit_work);
> >>> > -
> >>> > - complete_commit(commit);
> >>> > -
> >>> > - commit_destroy(commit);
> >>> > -}
[Bug 105300] amd-staging-drm-next-git 4.16 & RX 560 DL-DVI: corruption with refreshrates >73Hz when DPM changing VRAM clock
https://bugs.freedesktop.org/show_bug.cgi?id=105300 --- Comment #9 from Harry Wentland --- Are you messing with TMDS_MAX_PIXEL_CLOCK as Andrew is doing in this ticket: https://bugs.freedesktop.org/show_bug.cgi?id=105302 ? With DC clock switching might happen more aggressively which could explain the underflow you're seeing. -- 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 105302] [DC] - Maximum pixel clock of dual-link DVI too low for some modes
https://bugs.freedesktop.org/show_bug.cgi?id=105302 --- Comment #4 from Harry Wentland --- This sounds like a feature request, rather than a bug. -- 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/vc4: Ignore alpha on primary plane
Hey Ville, On Fri, Mar 2, 2018 at 3:43 PM, Ville Syrjälä wrote: > On Fri, Mar 02, 2018 at 04:39:22PM +0200, Ville Syrjälä wrote: >> If you want the plane to always be opaque you shouldn't expose any >> formats with alpha. >> >> Also what happens if one disables the primary plane? Or does the driver >> not allow that? > > Or just makes the plane not cover the entire screen? We've exposed alpha formats in the past so disabling that now would break userspace, certainly Android that chooses alpha-everything. The VC4 HVS has no fixed planes so I'll acknowledge that the concept of a primary plane is somewhat dubious and userspace could disable it or make it not cover the entire screen, making this ineffective. But then ultimately there doesn't seem to be a standard for what the display is supposed to be if you have transparent pixels with no plane to blend to below. This helps in the common case, the belts&braces fix would be to enable the VC4 HVS background color fill incurring a fixed overhead that in most cases is wasted because the composition ends up being opaque. Thanks, Stefan ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/vc4: Ignore alpha on primary plane
On Fri, Mar 02, 2018 at 04:06:58PM +0100, Stefan Schake wrote: > Hey Ville, > > On Fri, Mar 2, 2018 at 3:43 PM, Ville Syrjälä > wrote: > > On Fri, Mar 02, 2018 at 04:39:22PM +0200, Ville Syrjälä wrote: > >> If you want the plane to always be opaque you shouldn't expose any > >> formats with alpha. > >> > >> Also what happens if one disables the primary plane? Or does the driver > >> not allow that? > > > > Or just makes the plane not cover the entire screen? > > We've exposed alpha formats in the past so disabling that now would break > userspace, certainly Android that chooses alpha-everything. So it refuses to even run on hardware that can't do per-pixel alpha on the primary plane? > The VC4 HVS > has no fixed planes so I'll acknowledge that the concept of a primary plane > is somewhat dubious and userspace could disable it or make it not cover the > entire screen, making this ineffective. > > But then ultimately there doesn't seem to be a standard for what the display > is supposed to be if you have transparent pixels with no plane to blend to > below. The standard is black. IMO it's a driver bug if it fails to do that. > This helps in the common case, the belts&braces fix would be to > enable the VC4 HVS background color fill incurring a fixed overhead that > in most cases is wasted because the composition ends up being opaque. > > Thanks, > Stefan -- Ville Syrjälä Intel OTC ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 0/2] drm/panel: Add support for Raydium RM68200 panel
The Raydium Semiconductor Corporation RM68200 is a 5.5" 720x1280 TFT LCD panel connected using a MIPI-DSI video interface. Version 2: - Add Rob Herring Reviewed-by on dt-bindings. - Update Kconfig & driver thanks to Thierry Reding comments: no more DRV_NAME, DRM_WARN_ONCE instead of DRV_NAME where applicable, use backlight_enable/disable() & devm_of_find_backlight(), no extra gpio reset to 0, no more msg if successful, use RM68200 instead of rm68200 where necessary. Version 1: - Initial commit Philippe Cornu (2): dt-bindings/display/panel: Add support for Raydium rm68200 dsi panel drm/panel: Add support for Raydium RM68200 panel driver .../bindings/display/panel/raydium,rm68200.txt | 25 ++ drivers/gpu/drm/panel/Kconfig | 8 + drivers/gpu/drm/panel/Makefile | 1 + drivers/gpu/drm/panel/panel-raydium-rm68200.c | 437 + 4 files changed, 471 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/raydium,rm68200.txt create mode 100755 drivers/gpu/drm/panel/panel-raydium-rm68200.c -- 2.15.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/2] drm/panel: Add support for Raydium RM68200 panel driver
This patch adds Raydium Semiconductor Corporation RM68200
5.5" 720x1280 TFT LCD panel driver (MIPI-DSI video mode).
Signed-off-by: Philippe Cornu
---
drivers/gpu/drm/panel/Kconfig | 8 +
drivers/gpu/drm/panel/Makefile| 1 +
drivers/gpu/drm/panel/panel-raydium-rm68200.c | 437 ++
3 files changed, 446 insertions(+)
create mode 100755 drivers/gpu/drm/panel/panel-raydium-rm68200.c
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 988048ebcc22..a30eb7a2f8e2 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -108,6 +108,14 @@ config DRM_PANEL_RASPBERRYPI_TOUCHSCREEN
Pi 7" Touchscreen. To compile this driver as a module,
choose M here.
+config DRM_PANEL_RAYDIUM_RM68200
+ tristate "Raydium RM68200 720x1280 dsi video mode panel"
+ depends on OF
+ depends on DRM_MIPI_DSI
+ help
+ Say Y here if you want to enable support for Raydium RM68200
+ 720x1280 dsi video mode panel
+
config DRM_PANEL_SAMSUNG_S6E3HA2
tristate "Samsung S6E3HA2 DSI video mode panel"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 3d2a88d0e965..f26efc11d746 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -9,6 +9,7 @@ obj-$(CONFIG_DRM_PANEL_LG_LG4573) += panel-lg-lg4573.o
obj-$(CONFIG_DRM_PANEL_ORISETECH_OTM8009A) += panel-orisetech-otm8009a.o
obj-$(CONFIG_DRM_PANEL_PANASONIC_VVX10F034N00) +=
panel-panasonic-vvx10f034n00.o
obj-$(CONFIG_DRM_PANEL_RASPBERRYPI_TOUCHSCREEN) +=
panel-raspberrypi-touchscreen.o
+obj-$(CONFIG_DRM_PANEL_RAYDIUM_RM68200) += panel-raydium-rm68200.o
obj-$(CONFIG_DRM_PANEL_SAMSUNG_LD9040) += panel-samsung-ld9040.o
obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E3HA2) += panel-samsung-s6e3ha2.o
obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E63J0X03) += panel-samsung-s6e63j0x03.o
diff --git a/drivers/gpu/drm/panel/panel-raydium-rm68200.c
b/drivers/gpu/drm/panel/panel-raydium-rm68200.c
new file mode 100755
index ..35d75148ca08
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-raydium-rm68200.c
@@ -0,0 +1,437 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) STMicroelectronics SA 2017
+ *
+ * Authors: Philippe Cornu
+ * Yannick Fertre
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/*** Manufacturer Command Set ***/
+#define MCS_CMD_MODE_SW0xFE /* CMD Mode Switch */
+#define MCS_CMD1_UCS 0x00 /* User Command Set (UCS = CMD1) */
+#define MCS_CMD2_P00x01 /* Manufacture Command Set Page0 (CMD2 P0) */
+#define MCS_CMD2_P10x02 /* Manufacture Command Set Page1 (CMD2 P1) */
+#define MCS_CMD2_P20x03 /* Manufacture Command Set Page2 (CMD2 P2) */
+#define MCS_CMD2_P30x04 /* Manufacture Command Set Page3 (CMD2 P3) */
+
+/* CMD2 P0 commands (Display Options and Power) */
+#define MCS_STBCTR 0x12 /* TE1 Output Setting Zig-Zag Connection */
+#define MCS_SGOPCTR0x16 /* Source Bias Current */
+#define MCS_SDCTR 0x1A /* Source Output Delay Time */
+#define MCS_INVCTR 0x1B /* Inversion Type */
+#define MCS_EXT_PWR_IC 0x24 /* External PWR IC Control */
+#define MCS_SETAVDD0x27 /* PFM Control for AVDD Output */
+#define MCS_SETAVEE0x29 /* PFM Control for AVEE Output */
+#define MCS_BT2CTR 0x2B /* DDVDL Charge Pump Control */
+#define MCS_BT3CTR 0x2F /* VGH Charge Pump Control */
+#define MCS_BT4CTR 0x34 /* VGL Charge Pump Control */
+#define MCS_VCMCTR 0x46 /* VCOM Output Level Control */
+#define MCS_SETVGN 0x52 /* VG M/S N Control */
+#define MCS_SETVGP 0x54 /* VG M/S P Control */
+#define MCS_SW_CTRL0x5F /* Interface Control for PFM and MIPI */
+
+/* CMD2 P2 commands (GOA Timing Control) - no description in datasheet */
+#define GOA_VSTV1 0x00
+#define GOA_VSTV2 0x07
+#define GOA_VCLK1 0x0E
+#define GOA_VCLK2 0x17
+#define GOA_VCLK_OPT1 0x20
+#define GOA_BICLK1 0x2A
+#define GOA_BICLK2 0x37
+#define GOA_BICLK3 0x44
+#define GOA_BICLK4 0x4F
+#define GOA_BICLK_OPT1 0x5B
+#define GOA_BICLK_OPT2 0x60
+#define MCS_GOA_GPO1 0x6D
+#define MCS_GOA_GPO2 0x71
+#define MCS_GOA_EQ 0x74
+#define MCS_GOA_CLK_GALLON 0x7C
+#define MCS_GOA_FS_SEL00x7E
+#define MCS_GOA_FS_SEL10x87
+#define MCS_GOA_FS_SEL20x91
+#define MCS_GOA_FS_SEL30x9B
+#define MCS_GOA_BS_SEL00xAC
+#define MCS_GOA_BS_SEL10xB5
+#define MCS_GOA_BS_SEL20xBF
+#define MCS_GOA_BS_SEL30xC9
+#define MCS_GOA_BS_SEL40xD3
+
+/* CMD2 P3 commands (Gamma) */
+#define MCS_GAMMA_VP 0x60 /* Gamma VP1~VP16 */
+#define MCS_GAMMA_VN 0x70 /* Gamma VN1~VN16 */
+
+struct rm68200 {
+ struct device *dev;
+ struct drm_panel panel;
+ struct gpio_desc *reset_gpio;
+ struct regulator *supply;
+ struct backlight_device *backlight;
+ bool prepared;
+
[PATCH v2 1/2] dt-bindings/display/panel: Add support for Raydium rm68200 dsi panel
The Raydium Semiconductor Corporation RM68200 is a 5.5" 720x1280
TFT LCD panel connected using a MIPI-DSI video interface.
Reviewed-by: Rob Herring
Signed-off-by: Philippe Cornu
---
.../bindings/display/panel/raydium,rm68200.txt | 25 ++
1 file changed, 25 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/raydium,rm68200.txt
diff --git
a/Documentation/devicetree/bindings/display/panel/raydium,rm68200.txt
b/Documentation/devicetree/bindings/display/panel/raydium,rm68200.txt
new file mode 100644
index ..cbb79ef3bfc9
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/raydium,rm68200.txt
@@ -0,0 +1,25 @@
+Raydium Semiconductor Corporation RM68200 5.5" 720p MIPI-DSI TFT LCD panel
+
+The Raydium Semiconductor Corporation RM68200 is a 5.5" 720x1280 TFT LCD
+panel connected using a MIPI-DSI video interface.
+
+Required properties:
+ - compatible: "raydium,rm68200"
+ - reg: the virtual channel number of a DSI peripheral
+
+Optional properties:
+ - reset-gpios: a GPIO spec for the reset pin (active low).
+ - power-supply: phandle of the regulator that provides the supply voltage.
+ - backlight: phandle of the backlight device attached to the panel.
+
+Example:
+&dsi {
+ ...
+ panel@0 {
+ compatible = "raydium,rm68200";
+ reg = <0>;
+ reset-gpios = <&gpiof 15 GPIO_ACTIVE_LOW>;
+ power-supply = <&v1v8>;
+ backlight = <&pwm_backlight>;
+ };
+};
--
2.15.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 2/2] drm/panel: Add support for Raydium rm68200 panel driver
Hi Thierry, A big thank you for your code review and comments. It helped me to improve the driver and to send a v2. Philippe :-) On 02/28/2018 08:16 PM, Thierry Reding wrote: > On Thu, Feb 08, 2018 at 03:30:26PM +0100, Philippe Cornu wrote: >> This patch adds Raydium Semiconductor Corporation rm68200 >> 5.5" 720x1280 TFT LCD panel driver (MIPI-DSI video mode). >> >> Signed-off-by: Philippe Cornu >> --- >> drivers/gpu/drm/panel/Kconfig | 8 + >> drivers/gpu/drm/panel/Makefile| 1 + >> drivers/gpu/drm/panel/panel-raydium-rm68200.c | 464 >> ++ >> 3 files changed, 473 insertions(+) >> create mode 100755 drivers/gpu/drm/panel/panel-raydium-rm68200.c >> >> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig >> index 988048ebcc22..08d99dd46765 100644 >> --- a/drivers/gpu/drm/panel/Kconfig >> +++ b/drivers/gpu/drm/panel/Kconfig >> @@ -108,6 +108,14 @@ config DRM_PANEL_RASPBERRYPI_TOUCHSCREEN >>Pi 7" Touchscreen. To compile this driver as a module, >>choose M here. >> >> +config DRM_PANEL_RAYDIUM_RM68200 >> +tristate "Raydium rm68200 720x1280 dsi 2dl video mode panel" > > What's 2dl? Either this is something already implied by the RM68200 > model or if there are multiple variants of the RM68200 you'll probably > want to ensure that's reflected in the compatible string. > >> +depends on OF >> +depends on DRM_MIPI_DSI >> +help >> + Say Y here if you want to enable support for Raydium rm68200 >> + 720x1280 dsi 2dl video mode panel >> + >> config DRM_PANEL_SAMSUNG_S6E3HA2 >> tristate "Samsung S6E3HA2 DSI video mode panel" >> depends on OF >> diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile >> index 3d2a88d0e965..f26efc11d746 100644 >> --- a/drivers/gpu/drm/panel/Makefile >> +++ b/drivers/gpu/drm/panel/Makefile >> @@ -9,6 +9,7 @@ obj-$(CONFIG_DRM_PANEL_LG_LG4573) += panel-lg-lg4573.o >> obj-$(CONFIG_DRM_PANEL_ORISETECH_OTM8009A) += panel-orisetech-otm8009a.o >> obj-$(CONFIG_DRM_PANEL_PANASONIC_VVX10F034N00) += >> panel-panasonic-vvx10f034n00.o >> obj-$(CONFIG_DRM_PANEL_RASPBERRYPI_TOUCHSCREEN) += >> panel-raspberrypi-touchscreen.o >> +obj-$(CONFIG_DRM_PANEL_RAYDIUM_RM68200) += panel-raydium-rm68200.o >> obj-$(CONFIG_DRM_PANEL_SAMSUNG_LD9040) += panel-samsung-ld9040.o >> obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E3HA2) += panel-samsung-s6e3ha2.o >> obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E63J0X03) += panel-samsung-s6e63j0x03.o >> diff --git a/drivers/gpu/drm/panel/panel-raydium-rm68200.c >> b/drivers/gpu/drm/panel/panel-raydium-rm68200.c >> new file mode 100755 >> index ..f3e15873d05a >> --- /dev/null >> +++ b/drivers/gpu/drm/panel/panel-raydium-rm68200.c >> @@ -0,0 +1,464 @@ >> +// SPDX-License-Identifier: GPL-2.0 >> +/* >> + * Copyright (C) STMicroelectronics SA 2017 >> + * >> + * Authors: Philippe Cornu >> + * Yannick Fertre >> + */ >> + >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> + >> +#define DRV_NAME "raydium_rm68200" > > Not needed, see below. > >> + >> +/*** Manufacturer Command Set ***/ >> +#define MCS_CMD_MODE_SW 0xFE /* CMD Mode Switch */ >> +#define MCS_CMD1_UCS0x00 /* User Command Set (UCS = CMD1) */ >> +#define MCS_CMD2_P0 0x01 /* Manufacture Command Set Page0 (CMD2 P0) */ >> +#define MCS_CMD2_P1 0x02 /* Manufacture Command Set Page1 (CMD2 P1) */ >> +#define MCS_CMD2_P2 0x03 /* Manufacture Command Set Page2 (CMD2 P2) */ >> +#define MCS_CMD2_P3 0x04 /* Manufacture Command Set Page3 (CMD2 P3) */ >> + >> +/* CMD2 P0 commands (Display Options and Power) */ >> +#define MCS_STBCTR 0x12 /* TE1 Output Setting Zig-Zag Connection */ >> +#define MCS_SGOPCTR 0x16 /* Source Bias Current */ >> +#define MCS_SDCTR 0x1A /* Source Output Delay Time */ >> +#define MCS_INVCTR 0x1B /* Inversion Type */ >> +#define MCS_EXT_PWR_IC 0x24 /* External PWR IC Control */ >> +#define MCS_SETAVDD 0x27 /* PFM Control for AVDD Output */ >> +#define MCS_SETAVEE 0x29 /* PFM Control for AVEE Output */ >> +#define MCS_BT2CTR 0x2B /* DDVDL Charge Pump Control */ >> +#define MCS_BT3CTR 0x2F /* VGH Charge Pump Control */ >> +#define MCS_BT4CTR 0x34 /* VGL Charge Pump Control */ >> +#define MCS_VCMCTR 0x46 /* VCOM Output Level Control */ >> +#define MCS_SETVGN 0x52 /* VG M/S N Control */ >> +#define MCS_SETVGP 0x54 /* VG M/S P Control */ >> +#define MCS_SW_CTRL 0x5F /* Interface Control for PFM and MIPI */ >> + >> +/* CMD2 P2 commands (GOA Timing Control) - no description in datasheet */ >> +#define GOA_VSTV1 0x00 >> +#define GOA_VSTV2 0x07 >> +#define GOA_VCLK1 0x0E >> +#define GOA_VCLK2 0x17 >> +#define GOA_VCLK_OPT1 0x20 >> +#define GOA_BICLK1 0x2A >> +#define GOA_BICLK2 0x37 >> +#define GOA_BICLK3 0x44 >> +#define GOA_BICLK4 0x4F >> +#define GOA_BICLK_OPT1 0x5B >> +#define GOA_BICLK_OPT2 0x60 >> +#define MCS_GOA_GPO10x6D
[Bug 105302] [DC] - Maximum pixel clock of dual-link DVI too low for some modes
https://bugs.freedesktop.org/show_bug.cgi?id=105302 Alex Deucher changed: What|Removed |Added Severity|normal |enhancement --- Comment #5 from Alex Deucher --- I'd rather not support running things out of spec in the driver. The source is open. If you want to adjust the code allow something like that you can. -- 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 105300] amd-staging-drm-next-git 4.16 & RX 560 DL-DVI: corruption with refreshrates >73Hz when DPM changing VRAM clock
https://bugs.freedesktop.org/show_bug.cgi?id=105300 --- Comment #10 from tempel.jul...@gmail.com --- I thought of something similar too. But I'm far away from 330Mhz pixel clock. I'm just using LCD standard timings, which result in a pixel clock of 304.37MHz: https://abload.de/img/75hzhgs1d.png I also had the suspicion that the magic 300Mhz mark might be a problem, so I created a resolution with custom timings for 74Hz which resulted in ~295MHz, but the issue was still the same. It seems like it's really just about the refresh rate and not the timings or pixelclock. -- 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 0/4] drm/pl111: RealView and Versatile Express
On Fri, Mar 02, 2018 at 01:50:20PM +, Robin Murphy wrote:
> On 02/03/18 12:37, Linus Walleij wrote:
> > On Fri, Mar 2, 2018 at 1:11 PM, Robin Murphy wrote:
> > > On 02/03/18 09:09, Linus Walleij wrote:
> >
> > > > Also the Versatile Express CLCD on the motherboard has
> > > > a dedicated video memory, and cannot use CMA (ha! complex!)
> > > > and I will need to figure out a way to work around that.
> > > > The CLCDs synthesized on the core tiles for CA9 work
> > > > fine with this though.
> > >
> > > Out of curiosity, what's the issue with declaring the VRAM as a CMA
> > > region?
> > > That's certainly worked for stuff like local RAM on FPGA tiles in the
> > > past,
> > > and I can't think offhand of any way in which VExpress is wildly different
> > > (but I am of course open to being wrong...)
> >
> > There is nothing wrong with that apart from my ignorance
> > of that solution. So thanks! :D
> >
> > My experience with CMA is limited to using the 7 areas
> > that are defined by default in Kconfig and the DRM helpers
> > just plugging in on the front.
> >
> > Do you have some pointers? Is this something I can
> > handily just set up in the device tree?
>
> It should be - the inner workings of dma-{coherent,contiguous} are a maze of
> twisty little passages, all alike, and it'll take me a while to page the
> details back in, but IIRC it's mostly just a case of having a
> reserved-memory node covering the VRAM with the right combination of magic
> properties for rmem_dma_setup() to pick up, such that it gets assigned as
> the CLCD's private region. The subsequent "just plugging in" aspect doesn't
> change, it just makes allocations start taking this route under the covers:
>
> drm_gem_cma_create()
> dma_alloc_wc()
> dma_alloc_attrs()
> dma_alloc_from_dev_coherent()
>
> I could have sworn I've exchanged relevant FPGA DT fragments with Liviu in
> the past, but now I can't seem to find one to refer back to :(
Maybe something line this:
https://github.com/ARM-software/linux/blob/development/malidp/arch/arm64/boot/dts/arm/juno-base.dtsi#L792
And look at line 855 for the possible use of it.
That is how we currently make CMA allocate buffers in FPGA for the Mali
DP "hardware" (bitstream on FPGA) that we have in Juno.
Best regards,
Liviu
>
> Robin.
--
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---
¯\_(ツ)_/¯
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 01/10] video: stm32: stm32_ltdc: add bridge to display controller
Manage a bridge insert between the display controller & a panel.
Signed-off-by: yannick fertre
---
drivers/video/stm32/stm32_ltdc.c | 107 ++-
1 file changed, 71 insertions(+), 36 deletions(-)
diff --git a/drivers/video/stm32/stm32_ltdc.c b/drivers/video/stm32/stm32_ltdc.c
index e160c77..bd9c0de 100644
--- a/drivers/video/stm32/stm32_ltdc.c
+++ b/drivers/video/stm32/stm32_ltdc.c
@@ -8,6 +8,7 @@
#include
#include
+#include
#include
#include
#include
@@ -15,12 +16,12 @@
#include
#include
#include
+#include
DECLARE_GLOBAL_DATA_PTR;
struct stm32_ltdc_priv {
void __iomem *regs;
- struct display_timing timing;
enum video_log2_bpp l2bpp;
u32 bg_col_argb;
u32 crop_x, crop_y, crop_w, crop_h;
@@ -210,23 +211,23 @@ static void stm32_ltdc_enable(struct stm32_ltdc_priv
*priv)
setbits_le32(priv->regs + LTDC_GCR, GCR_LTDCEN);
}
-static void stm32_ltdc_set_mode(struct stm32_ltdc_priv *priv)
+static void stm32_ltdc_set_mode(struct stm32_ltdc_priv *priv,
+ struct display_timing *timings)
{
void __iomem *regs = priv->regs;
- struct display_timing *timing = &priv->timing;
u32 hsync, vsync, acc_hbp, acc_vbp, acc_act_w, acc_act_h;
u32 total_w, total_h;
u32 val;
/* Convert video timings to ltdc timings */
- hsync = timing->hsync_len.typ - 1;
- vsync = timing->vsync_len.typ - 1;
- acc_hbp = hsync + timing->hback_porch.typ;
- acc_vbp = vsync + timing->vback_porch.typ;
- acc_act_w = acc_hbp + timing->hactive.typ;
- acc_act_h = acc_vbp + timing->vactive.typ;
- total_w = acc_act_w + timing->hfront_porch.typ;
- total_h = acc_act_h + timing->vfront_porch.typ;
+ hsync = timings->hsync_len.typ - 1;
+ vsync = timings->vsync_len.typ - 1;
+ acc_hbp = hsync + timings->hback_porch.typ;
+ acc_vbp = vsync + timings->vback_porch.typ;
+ acc_act_w = acc_hbp + timings->hactive.typ;
+ acc_act_h = acc_vbp + timings->vactive.typ;
+ total_w = acc_act_w + timings->hfront_porch.typ;
+ total_h = acc_act_h + timings->vfront_porch.typ;
/* Synchronization sizes */
val = (hsync << 16) | vsync;
@@ -248,14 +249,14 @@ static void stm32_ltdc_set_mode(struct stm32_ltdc_priv
*priv)
/* Signal polarities */
val = 0;
- debug("%s: timing->flags 0x%08x\n", __func__, timing->flags);
- if (timing->flags & DISPLAY_FLAGS_HSYNC_HIGH)
+ debug("%s: timing->flags 0x%08x\n", __func__, timings->flags);
+ if (timings->flags & DISPLAY_FLAGS_HSYNC_HIGH)
val |= GCR_HSPOL;
- if (timing->flags & DISPLAY_FLAGS_VSYNC_HIGH)
+ if (timings->flags & DISPLAY_FLAGS_VSYNC_HIGH)
val |= GCR_VSPOL;
- if (timing->flags & DISPLAY_FLAGS_DE_HIGH)
+ if (timings->flags & DISPLAY_FLAGS_DE_HIGH)
val |= GCR_DEPOL;
- if (timing->flags & DISPLAY_FLAGS_PIXDATA_NEGEDGE)
+ if (timings->flags & DISPLAY_FLAGS_PIXDATA_NEGEDGE)
val |= GCR_PCPOL;
clrsetbits_le32(regs + LTDC_GCR,
GCR_HSPOL | GCR_VSPOL | GCR_DEPOL | GCR_PCPOL, val);
@@ -331,7 +332,11 @@ static int stm32_ltdc_probe(struct udevice *dev)
struct video_uc_platdata *uc_plat = dev_get_uclass_platdata(dev);
struct video_priv *uc_priv = dev_get_uclass_priv(dev);
struct stm32_ltdc_priv *priv = dev_get_priv(dev);
- struct udevice *panel;
+#ifdef CONFIG_VIDEO_BRIDGE
+ struct udevice *bridge = NULL;
+#endif
+ struct udevice *panel = NULL;
+ struct display_timing timings;
struct clk pclk;
struct reset_ctl rst;
int rate, ret;
@@ -364,63 +369,93 @@ static int stm32_ltdc_probe(struct udevice *dev)
/* Reset */
reset_deassert(&rst);
- ret = uclass_first_device(UCLASS_PANEL, &panel);
+#ifdef CONFIG_VIDEO_BRIDGE
+ ret = uclass_get_device(UCLASS_VIDEO_BRIDGE, 0, &bridge);
if (ret) {
- debug("%s: panel device error %d\n", __func__, ret);
- return ret;
+ debug("%s: No video bridge, or no backlight on bridge\n",
+ __func__);
}
- ret = panel_enable_backlight(panel);
+ if (bridge) {
+ ret = video_bridge_attach(bridge);
+ if (ret) {
+ debug("%s: fail to attach bridge\n", __func__);
+ return ret;
+ }
+ }
+#endif
+ ret = uclass_first_device(UCLASS_PANEL, &panel);
if (ret) {
- debug("%s: panel %s enable backlight error %d\n",
- __func__, panel->name, ret);
+ debug("%s: panel device error %d\n", __func__, ret);
return ret;
}
- ret = fdtdec_decode_display_timing(gd->fdt_blob,
- dev_of_offset(dev)
[PATCH v2 08/10] arm: dts: stm32: add dsi for STM32F746
Add mipi dsi bridge node in device-tree.
Signed-off-by: yannick fertre
---
arch/arm/dts/stm32f746.dtsi | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/dts/stm32f746.dtsi b/arch/arm/dts/stm32f746.dtsi
index e4d32bf..4ec954d 100644
--- a/arch/arm/dts/stm32f746.dtsi
+++ b/arch/arm/dts/stm32f746.dtsi
@@ -332,6 +332,18 @@
u-boot,dm-pre-reloc;
status = "disabled";
};
+
+ dsi: dsi@40016c00 {
+ compatible = "st,stm32-dsi";
+ reg = <0x40016C00 0x800>;
+ resets = <&rcc STM32F7_APB2_RESET(DSI)>;
+ clocks = <&rcc 0 STM32F7_APB2_CLOCK(DSI)>,
+ <&rcc 0 STM32F7_APB2_CLOCK(LTDC)>,
+ <&clk_hse>;
+ clock-names = "pclk", "px_clk", "ref";
+ u-boot,dm-pre-reloc;
+ status = "disabled";
+ };
};
};
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 03/10] video: add support of MIPI DSI interface
Mipi_display.c contains a set of dsi helpers.
This file is a copy of file drm_mipi_dsi.c (linux kernel).
Signed-off-by: yannick fertre
---
drivers/video/Kconfig| 7 +
drivers/video/Makefile | 1 +
drivers/video/mipi_display.c | 807 +++
include/mipi_display.h | 257 +-
4 files changed, 1071 insertions(+), 1 deletion(-)
create mode 100644 drivers/video/mipi_display.c
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 2fc0def..1981298 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -75,6 +75,13 @@ config VIDEO_ANSI
Enable ANSI escape sequence decoding for a more fully functional
console.
+config VIDEO_MIPI_DSI
+ bool "Support MIPI DSI interface"
+ depends on DM_VIDEO
+ default y if DM_VIDEO
+ help
+ Support MIPI DSI interface for driving a MIPI compatible LCD panel.
+
config CONSOLE_NORMAL
bool "Support a simple text console"
depends on DM_VIDEO
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index dfafe08..6f42cca 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -52,6 +52,7 @@ obj-$(CONFIG_FORMIKE) += formike.o
obj-$(CONFIG_LG4573) += lg4573.o
obj-$(CONFIG_AM335X_LCD) += am335x-fb.o
obj-$(CONFIG_VIDEO_DW_HDMI) += dw_hdmi.o
+obj-${CONFIG_VIDEO_MIPI_DSI} += mipi_display.o
obj-$(CONFIG_VIDEO_SIMPLE) += simplefb.o
obj-${CONFIG_VIDEO_TEGRA124} += tegra124/
obj-${CONFIG_EXYNOS_FB} += exynos/
diff --git a/drivers/video/mipi_display.c b/drivers/video/mipi_display.c
new file mode 100644
index 000..d90ff5d
--- /dev/null
+++ b/drivers/video/mipi_display.c
@@ -0,0 +1,807 @@
+/*
+ * MIPI DSI Bus
+ *
+ * Copyright (C) 2012-2013, Samsung Electronics, Co., Ltd.
+ * Copyright (C) 2018 STMicroelectronics - All Rights Reserved
+ * Andrzej Hajda
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the
+ * "Software"), to deal in the Software without restriction, including
+ * without limitation the rights to use, copy, modify, merge, publish,
+ * distribute, sub license, and/or sell copies of the Software, and to
+ * permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the
+ * next paragraph) shall be included in all copies or substantial portions
+ * of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDERS, AUTHORS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM,
+ * DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
+ * OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE
+ * USE OR OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+/**
+ * DOC: dsi helpers
+ *
+ * These functions contain some common logic and helpers to deal with MIPI DSI
+ * peripherals.
+ *
+ * Helpers are provided for a number of standard MIPI DSI command as well as a
+ * subset of the MIPI DCS command set.
+ */
+
+/**
+ * mipi_dsi_attach - attach a DSI device to its DSI host
+ * @dsi: DSI peripheral
+ */
+int mipi_dsi_attach(struct mipi_dsi_device *dsi)
+{
+ const struct mipi_dsi_host_ops *ops = dsi->host->ops;
+
+ if (!ops || !ops->attach)
+ return -ENOSYS;
+
+ return ops->attach(dsi->host, dsi);
+}
+EXPORT_SYMBOL(mipi_dsi_attach);
+
+/**
+ * mipi_dsi_detach - detach a DSI device from its DSI host
+ * @dsi: DSI peripheral
+ */
+int mipi_dsi_detach(struct mipi_dsi_device *dsi)
+{
+ const struct mipi_dsi_host_ops *ops = dsi->host->ops;
+
+ if (!ops || !ops->detach)
+ return -ENOSYS;
+
+ return ops->detach(dsi->host, dsi);
+}
+EXPORT_SYMBOL(mipi_dsi_detach);
+
+static ssize_t mipi_dsi_device_transfer(struct mipi_dsi_device *dsi,
+ struct mipi_dsi_msg *msg)
+{
+ const struct mipi_dsi_host_ops *ops = dsi->host->ops;
+
+ if (!ops || !ops->transfer)
+ return -ENOSYS;
+
+ if (dsi->mode_flags & MIPI_DSI_MODE_LPM)
+ msg->flags |= MIPI_DSI_MSG_USE_LPM;
+
+ return ops->transfer(dsi->host, msg);
+}
+
+/**
+ * mipi_dsi_packet_format_is_short - check if a packet is of the short format
+ * @type: MIPI DSI data type of the packet
+ *
+ * Return: true if the packet for the given data type is a short packet, false
+ * otherwise.
+ */
+bool mipi_dsi_packet_format_is_short(u8 type)
+{
+ switch (type) {
+ case MIPI_DSI_V_SYNC_START:
+ case MIPI_DSI_V_SYNC_END:
+ case MIPI_DSI_H_SYNC_START:
+ case MIPI_DSI_H_SYNC_END:
+ case MIPI_DSI_END_OF_TRANSMISSION:
+
[PATCH v2 06/10] video: add support of STM32 MIPI DSI controller driver
Add the STM32 DSI controller driver that uses the Synopsys DesignWare
MIPI DSI host controller bridge.
Signed-off-by: yannick fertre
---
drivers/video/stm32/Kconfig | 10 +
drivers/video/stm32/Makefile| 1 +
drivers/video/stm32/stm32_dsi.c | 427
3 files changed, 438 insertions(+)
create mode 100644 drivers/video/stm32/stm32_dsi.c
diff --git a/drivers/video/stm32/Kconfig b/drivers/video/stm32/Kconfig
index 113a2bb..2ea6f18 100644
--- a/drivers/video/stm32/Kconfig
+++ b/drivers/video/stm32/Kconfig
@@ -15,6 +15,16 @@ menuconfig VIDEO_STM32
DSI. This option enables these supports which can be used on
devices which have RGB TFT or DSI display connected.
+config VIDEO_STM32_DSI
+ bool "Enable STM32 DSI video support"
+ depends on VIDEO_STM32
+ select VIDEO_MIPI_DSI
+ select VIDEO_BRIDGE
+ select VIDEO_DW_MIPI_DSI
+ help
+ This option enables support DSI internal bridge which can be used on
+ devices which have DSI display connected.
+
config VIDEO_STM32_MAX_XRES
int "Maximum horizontal resolution (for memory allocation purposes)"
depends on VIDEO_STM32
diff --git a/drivers/video/stm32/Makefile b/drivers/video/stm32/Makefile
index 372a2e1..f8c3ff7 100644
--- a/drivers/video/stm32/Makefile
+++ b/drivers/video/stm32/Makefile
@@ -8,3 +8,4 @@
#
obj-${CONFIG_VIDEO_STM32} = stm32_ltdc.o
+obj-${CONFIG_VIDEO_STM32_DSI} += stm32_dsi.o
diff --git a/drivers/video/stm32/stm32_dsi.c b/drivers/video/stm32/stm32_dsi.c
new file mode 100644
index 000..3e26433
--- /dev/null
+++ b/drivers/video/stm32/stm32_dsi.c
@@ -0,0 +1,427 @@
+/*
+ * Copyright (C) 2018 STMicroelectronics - All Rights Reserved
+ * Author(s): Philippe Cornu for STMicroelectronics.
+ * Yannick Fertre for STMicroelectronics.
+ *
+ * This driver is based on the mipi dsi driver from
+ * drivers/gpu/drm/stm/dw_mipi_dsi-stm.c (kernel linux).
+ *
+ * SPDX-License-Identifier: GPL-2.0
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+DECLARE_GLOBAL_DATA_PTR;
+
+#define HWVER_130 0x31333000 /* IP version 1.30 */
+#define HWVER_131 0x31333100 /* IP version 1.31 */
+
+/* DSI digital registers & bit definitions */
+#define DSI_VERSION0x00
+#define VERSIONGENMASK(31, 8)
+
+/*
+ * DSI wrapper registers & bit definitions
+ * Note: registers are named as in the Reference Manual
+ */
+#define DSI_WCFGR 0x0400 /* Wrapper ConFiGuration Reg */
+#define WCFGR_DSIM BIT(0) /* DSI Mode */
+#define WCFGR_COLMUX GENMASK(3, 1) /* COLor MUltipleXing */
+
+#define DSI_WCR0x0404 /* Wrapper Control Reg */
+#define WCR_DSIEN BIT(3) /* DSI ENable */
+
+#define DSI_WISR 0x040C /* Wrapper Interrupt and Status Reg */
+#define WISR_PLLLS BIT(8) /* PLL Lock Status */
+#define WISR_RRS BIT(12) /* Regulator Ready Status */
+
+#define DSI_WPCR0 0x0418 /* Wrapper Phy Conf Reg 0 */
+#define WPCR0_UIX4 GENMASK(5, 0) /* Unit Interval X 4 */
+#define WPCR0_TDDL BIT(16) /* Turn Disable Data Lanes */
+
+#define DSI_WRPCR 0x0430 /* Wrapper Regulator & Pll Ctrl Reg */
+#define WRPCR_PLLENBIT(0) /* PLL ENable */
+#define WRPCR_NDIV GENMASK(8, 2) /* pll loop DIVision Factor */
+#define WRPCR_IDF GENMASK(14, 11) /* pll Input Division Factor */
+#define WRPCR_ODF GENMASK(17, 16) /* pll Output Division Factor */
+#define WRPCR_REGENBIT(24) /* REGulator ENable */
+#define WRPCR_BGRENBIT(28) /* BandGap Reference ENable */
+#define IDF_MIN1
+#define IDF_MAX7
+#define NDIV_MIN 10
+#define NDIV_MAX 125
+#define ODF_MIN1
+#define ODF_MAX8
+
+/* dsi color format coding according to the datasheet */
+enum dsi_color {
+ DSI_RGB565_CONF1,
+ DSI_RGB565_CONF2,
+ DSI_RGB565_CONF3,
+ DSI_RGB666_CONF1,
+ DSI_RGB666_CONF2,
+ DSI_RGB888,
+};
+
+#define LANE_MIN_KBPS 31250
+#define LANE_MAX_KBPS 50
+
+/* Timeout for regulator on/off, pll lock/unlock & fifo empty */
+#define TIMEOUT_US 20
+
+struct stm32_dsi_priv {
+ struct mipi_dsi_device device;
+ void __iomem *base;
+ struct udevice *panel;
+ u32 pllref_clk;
+ u32 hw_version;
+ int lane_min_kbps;
+ int lane_max_kbps;
+};
+
+static inline void dsi_write(struct stm32_dsi_priv *dsi, u32 reg, u32 val)
+{
+ writel(val, dsi->base + reg);
+}
+
+static inline u32 dsi_read(struct stm32_dsi_priv *dsi, u32 reg)
+{
+ return readl(dsi->base + reg);
+}
+
+static inline void dsi_set(struct stm32_dsi_priv *dsi, u32 reg, u32 mask)
+{
+ dsi_wr
[PATCH v2 04/10] video: add support of panel OTM8009A
Support for Orise Tech otm8009a 480p dsi 2dl video mode panel.
Signed-off-by: yannick fertre
---
drivers/video/Kconfig | 8 +
drivers/video/Makefile | 1 +
drivers/video/orisetech_otm8009a.c | 329 +
3 files changed, 338 insertions(+)
create mode 100644 drivers/video/orisetech_otm8009a.c
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 1981298..b5fc535 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -320,6 +320,14 @@ config VIDEO_LCD_ANX9804
from a parallel LCD interface and translate it on the fy into a DP
interface for driving eDP TFT displays. It uses I2C for configuration.
+config VIDEO_LCD_ORISETECH_OTM8009A
+ bool "OTM8009A DSI LCD panel support"
+ depends on DM_VIDEO
+ select VIDEO_MIPI_DSI
+ default n
+ ---help---
+ Support for Orise Tech otm8009a 480p dsi 2dl video mode panel.
+
config VIDEO_LCD_SSD2828
bool "SSD2828 bridge chip"
default n
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index 6f42cca..65002af 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -37,6 +37,7 @@ obj-$(CONFIG_VIDEO_COREBOOT) += coreboot.o
obj-$(CONFIG_VIDEO_DA8XX) += da8xx-fb.o videomodes.o
obj-$(CONFIG_VIDEO_LCD_ANX9804) += anx9804.o
obj-$(CONFIG_VIDEO_LCD_HITACHI_TX18D42VM) += hitachi_tx18d42vm_lcd.o
+obj-$(CONFIG_VIDEO_LCD_ORISETECH_OTM8009A) += orisetech_otm8009a.o
obj-$(CONFIG_VIDEO_LCD_SSD2828) += ssd2828.o
obj-$(CONFIG_VIDEO_MB862xx) += mb862xx.o videomodes.o
obj-$(CONFIG_VIDEO_MX3) += mx3fb.o videomodes.o
diff --git a/drivers/video/orisetech_otm8009a.c
b/drivers/video/orisetech_otm8009a.c
new file mode 100644
index 000..79f2da8
--- /dev/null
+++ b/drivers/video/orisetech_otm8009a.c
@@ -0,0 +1,329 @@
+/*
+ * Copyright (C) 2018 STMicroelectronics - All Rights Reserved
+ * Author(s): Yannick Fertre for STMicroelectronics.
+ * Philippe Cornu for STMicroelectronics.
+ *
+ * This otm8009a panel driver is based on the panel driver from
+ * drivers/gpu/drm/panel/panel-orisetech-otm8009a.c (kernel linux)
+ *
+ * SPDX-License-Identifier: GPL-2.0
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+DECLARE_GLOBAL_DATA_PTR;
+
+#define DRV_NAME "orisetech_otm8009a"
+
+#define OTM8009A_BACKLIGHT_DEFAULT 240
+#define OTM8009A_BACKLIGHT_MAX 255
+
+/* Manufacturer Command Set */
+#define MCS_ADRSFT 0x /* Address Shift Function */
+#define MCS_PANSET 0xB3A6 /* Panel Type Setting */
+#define MCS_SD_CTRL0xC0A2 /* Source Driver Timing Setting */
+#define MCS_P_DRV_M0xC0B4 /* Panel Driving Mode */
+#define MCS_OSC_ADJ0xC181 /* Oscillator Adjustment for Idle/Normal mode */
+#define MCS_RGB_VID_SET0xC1A1 /* RGB Video Mode Setting */
+#define MCS_SD_PCH_CTRL0xC480 /* Source Driver Precharge Control */
+#define MCS_NO_DOC10xC48A /* Command not documented */
+#define MCS_PWR_CTRL1 0xC580 /* Power Control Setting 1 */
+#define MCS_PWR_CTRL2 0xC590 /* Power Control Setting 2 for Normal Mode */
+#define MCS_PWR_CTRL4 0xC5B0 /* Power Control Setting 4 for DC Voltage */
+#define MCS_PANCTRLSET10xCB80 /* Panel Control Setting 1 */
+#define MCS_PANCTRLSET20xCB90 /* Panel Control Setting 2 */
+#define MCS_PANCTRLSET30xCBA0 /* Panel Control Setting 3 */
+#define MCS_PANCTRLSET40xCBB0 /* Panel Control Setting 4 */
+#define MCS_PANCTRLSET50xCBC0 /* Panel Control Setting 5 */
+#define MCS_PANCTRLSET60xCBD0 /* Panel Control Setting 6 */
+#define MCS_PANCTRLSET70xCBE0 /* Panel Control Setting 7 */
+#define MCS_PANCTRLSET80xCBF0 /* Panel Control Setting 8 */
+#define MCS_PANU2D10xCC80 /* Panel U2D Setting 1 */
+#define MCS_PANU2D20xCC90 /* Panel U2D Setting 2 */
+#define MCS_PANU2D30xCCA0 /* Panel U2D Setting 3 */
+#define MCS_PAND2U10xCCB0 /* Panel D2U Setting 1 */
+#define MCS_PAND2U20xCCC0 /* Panel D2U Setting 2 */
+#define MCS_PAND2U30xCCD0 /* Panel D2U Setting 3 */
+#define MCS_GOAVST 0xCE80 /* GOA VST Setting */
+#define MCS_GOACLKA1 0xCEA0 /* GOA CLKA1 Setting */
+#define MCS_GOACLKA3 0xCEB0 /* GOA CLKA3 Setting */
+#define MCS_GOAECLK0xCFC0 /* GOA ECLK Setting */
+#define MCS_NO_DOC20xCFD0 /* Command not documented */
+#define MCS_GVDDSET0xD800 /* GVDD/NGVDD */
+#define MCS_VCOMDC 0xD900 /* VCOM Voltage Setting */
+#define MCS_GMCT2_2P 0xE100 /* Gamma Correction 2.2+ Setting */
+#define MCS_GMCT2_2N 0xE200 /* Gamma Correction 2.2- Setting */
+#define MCS_NO_DOC30xF5B6 /* Command not documented */
+#define MCS_CMD2_ENA1 0xFF00 /* Enable Access Command2 "CMD2" */
+#define MCS_CMD2_ENA2 0xFF80 /* Enable Access Orise Command2 */
+
+struct otm8009a_panel_priv {
+ struct udevice *reg;
+ struct gpio_desc reset;
+};
+
+static void otm8009a_dcs_write_buf(struct udevice *dev
[PATCH v2 07/10] video: add support of panel rm68200
Support for Raydium rm68200 720p dsi 2dl video mode panel.
Signed-off-by: yannick fertre
---
drivers/video/Kconfig | 8 +
drivers/video/Makefile | 1 +
drivers/video/raydium-rm68200.c | 329
3 files changed, 338 insertions(+)
create mode 100644 drivers/video/raydium-rm68200.c
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 0f641d7..2561c59 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -328,6 +328,14 @@ config VIDEO_LCD_ORISETECH_OTM8009A
---help---
Support for Orise Tech otm8009a 480p dsi 2dl video mode panel.
+config VIDEO_LCD_RAYDIUM_RM68200
+ bool "RM68200 DSI LCD panel support"
+ depends on DM_VIDEO
+ select VIDEO_MIPI_DSI
+ default n
+ ---help---
+ Support for Raydium rm68200 720x1280 dsi 2dl video mode panel.
+
config VIDEO_LCD_SSD2828
bool "SSD2828 bridge chip"
default n
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index 50be569..1a6c8d3 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -38,6 +38,7 @@ obj-$(CONFIG_VIDEO_DA8XX) += da8xx-fb.o videomodes.o
obj-$(CONFIG_VIDEO_LCD_ANX9804) += anx9804.o
obj-$(CONFIG_VIDEO_LCD_HITACHI_TX18D42VM) += hitachi_tx18d42vm_lcd.o
obj-$(CONFIG_VIDEO_LCD_ORISETECH_OTM8009A) += orisetech_otm8009a.o
+obj-$(CONFIG_VIDEO_LCD_RAYDIUM_RM68200) += raydium-rm68200.o
obj-$(CONFIG_VIDEO_LCD_SSD2828) += ssd2828.o
obj-$(CONFIG_VIDEO_MB862xx) += mb862xx.o videomodes.o
obj-$(CONFIG_VIDEO_MX3) += mx3fb.o videomodes.o
diff --git a/drivers/video/raydium-rm68200.c b/drivers/video/raydium-rm68200.c
new file mode 100644
index 000..46afb58
--- /dev/null
+++ b/drivers/video/raydium-rm68200.c
@@ -0,0 +1,329 @@
+/*
+ * Copyright (C) 2018 STMicroelectronics - All Rights Reserved
+ * Author(s): Yannick Fertre for STMicroelectronics.
+ * Philippe Cornu for STMicroelectronics.
+ *
+ * This rm68200 panel driver is based on the panel driver from
+ * drivers/gpu/drm/panel/panel-raydium-rm68200.c (kernel linux)
+ *
+ * SPDX-License-Identifier: GPL-2.0
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+DECLARE_GLOBAL_DATA_PTR;
+
+#define DRV_NAME "raydium_rm68200"
+
+/*** Manufacturer Command Set ***/
+#define MCS_CMD_MODE_SW0xFE /* CMD Mode Switch */
+#define MCS_CMD1_UCS 0x00 /* User Command Set (UCS = CMD1) */
+#define MCS_CMD2_P00x01 /* Manufacture Command Set Page0 (CMD2 P0) */
+#define MCS_CMD2_P10x02 /* Manufacture Command Set Page1 (CMD2 P1) */
+#define MCS_CMD2_P20x03 /* Manufacture Command Set Page2 (CMD2 P2) */
+#define MCS_CMD2_P30x04 /* Manufacture Command Set Page3 (CMD2 P3) */
+
+/* CMD2 P0 commands (Display Options and Power) */
+#define MCS_STBCTR 0x12 /* TE1 Output Setting Zig-Zag Connection */
+#define MCS_SGOPCTR0x16 /* Source Bias Current */
+#define MCS_SDCTR 0x1A /* Source Output Delay Time */
+#define MCS_INVCTR 0x1B /* Inversion Type */
+#define MCS_EXT_PWR_IC 0x24 /* External PWR IC Control */
+#define MCS_SETAVDD0x27 /* PFM Control for AVDD Output */
+#define MCS_SETAVEE0x29 /* PFM Control for AVEE Output */
+#define MCS_BT2CTR 0x2B /* DDVDL Charge Pump Control */
+#define MCS_BT3CTR 0x2F /* VGH Charge Pump Control */
+#define MCS_BT4CTR 0x34 /* VGL Charge Pump Control */
+#define MCS_VCMCTR 0x46 /* VCOM Output Level Control */
+#define MCS_SETVGN 0x52 /* VG M/S N Control */
+#define MCS_SETVGP 0x54 /* VG M/S P Control */
+#define MCS_SW_CTRL0x5F /* Interface Control for PFM and MIPI */
+
+/* CMD2 P2 commands (GOA Timing Control) - no description in datasheet */
+#define GOA_VSTV1 0x00
+#define GOA_VSTV2 0x07
+#define GOA_VCLK1 0x0E
+#define GOA_VCLK2 0x17
+#define GOA_VCLK_OPT1 0x20
+#define GOA_BICLK1 0x2A
+#define GOA_BICLK2 0x37
+#define GOA_BICLK3 0x44
+#define GOA_BICLK4 0x4F
+#define GOA_BICLK_OPT1 0x5B
+#define GOA_BICLK_OPT2 0x60
+#define MCS_GOA_GPO1 0x6D
+#define MCS_GOA_GPO2 0x71
+#define MCS_GOA_EQ 0x74
+#define MCS_GOA_CLK_GALLON 0x7C
+#define MCS_GOA_FS_SEL00x7E
+#define MCS_GOA_FS_SEL10x87
+#define MCS_GOA_FS_SEL20x91
+#define MCS_GOA_FS_SEL30x9B
+#define MCS_GOA_BS_SEL00xAC
+#define MCS_GOA_BS_SEL10xB5
+#define MCS_GOA_BS_SEL20xBF
+#define MCS_GOA_BS_SEL30xC9
+#define MCS_GOA_BS_SEL40xD3
+
+/* CMD2 P3 commands (Gamma) */
+#define MCS_GAMMA_VP 0x60 /* Gamma VP1~VP16 */
+#define MCS_GAMMA_VN 0x70 /* Gamma VN1~VN16 */
+
+struct rm68200_panel_priv {
+ struct udevice *reg;
+ struct udevice *backlight;
+ struct gpio_desc reset;
+};
+
+static void rm68200_dcs_write_buf(struct udevice *dev, const void *data,
+ size_t len)
+{
+ struct mipi_dsi_panel_plat *plat = dev_get_platdata(dev);
+ struct mipi_dsi_device *device = plat->device;
+
+ if
[PATCH v2 00/10] splash screen on the stm32f769 disco board
Version 2: - Replace debug log by pr_error, pr_warn or pr_info. - Rework bridge between ltdc & dsi panel - Rework backligh management (with or witout gpio) - Rework panel otm8009a - Add new panel raydium rm68200 Version 1: - Initial commit This serie contains all patchsets needed for displaying a splash screen on the stm32f769 disco board. yannick fertre (10): video: stm32: stm32_ltdc: add bridge to display controller video: stm32: stm32_ltdc: update debug log video: add support of MIPI DSI interface video: add support of panel OTM8009A video: add MIPI DSI host controller bridge video: add support of STM32 MIPI DSI controller driver video: add support of panel rm68200 arm: dts: stm32: add dsi for STM32F746 arm: dts: stm32: add display for STM32F769 disco board board: Add STM32F769 SoC, discovery board support arch/arm/dts/stm32f746.dtsi| 12 + arch/arm/dts/stm32f769-disco.dts | 71 configs/stm32f769-disco_defconfig | 63 +++ drivers/video/Kconfig | 32 ++ drivers/video/Makefile | 4 + drivers/video/dw_mipi_dsi.c| 822 + drivers/video/mipi_display.c | 807 drivers/video/orisetech_otm8009a.c | 329 +++ drivers/video/raydium-rm68200.c| 329 +++ drivers/video/stm32/Kconfig| 10 + drivers/video/stm32/Makefile | 1 + drivers/video/stm32/stm32_dsi.c| 427 +++ drivers/video/stm32/stm32_ltdc.c | 144 --- include/dw_mipi_dsi.h | 32 ++ include/mipi_display.h | 257 +++- 15 files changed, 3285 insertions(+), 55 deletions(-) create mode 100644 configs/stm32f769-disco_defconfig create mode 100644 drivers/video/dw_mipi_dsi.c create mode 100644 drivers/video/mipi_display.c create mode 100644 drivers/video/orisetech_otm8009a.c create mode 100644 drivers/video/raydium-rm68200.c create mode 100644 drivers/video/stm32/stm32_dsi.c create mode 100644 include/dw_mipi_dsi.h -- 1.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 09/10] arm: dts: stm32: add display for STM32F769 disco board
Enable the display controller, mipi dsi bridge & panel.
Set panel display timings.
Signed-off-by: yannick fertre
---
arch/arm/dts/stm32f769-disco.dts | 71
1 file changed, 71 insertions(+)
diff --git a/arch/arm/dts/stm32f769-disco.dts b/arch/arm/dts/stm32f769-disco.dts
index 59c9d31..82985b9 100644
--- a/arch/arm/dts/stm32f769-disco.dts
+++ b/arch/arm/dts/stm32f769-disco.dts
@@ -42,6 +42,7 @@
/dts-v1/;
#include "stm32f746.dtsi"
+#include
#include
/ {
@@ -264,3 +265,73 @@
bus-width = <4>;
max-frequency = <2500>;
};
+
+;
+ #size-cells = <0>;
+
+ ltdc_out_dsi: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&dsi_in>;
+ };
+ };
+};
+
+&dsi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "okay";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ dsi_in: endpoint {
+ remote-endpoint = <;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ dsi_out: endpoint {
+ remote-endpoint = <&dsi_panel_in>;
+ };
+ };
+ };
+
+ panel-dsi@0 {
+ compatible = "orisetech,otm8009a";
+ reg = <0>; /* dsi virtual channel (0..3) */
+ reset-gpios = <&gpioj 15 GPIO_ACTIVE_LOW>;
+ status = "okay";
+
+ port {
+ dsi_panel_in: endpoint {
+ remote-endpoint = <&dsi_out>;
+ };
+ };
+
+ display-timings {
+ timing@0 {
+ clock-frequency = <32729000>;
+ hactive = <480>;
+ hfront-porch = <120>;
+ hback-porch = <63>;
+ hsync-len = <120>;
+ vactive = <800>;
+ vfront-porch = <12>;
+ vback-porch = <12>;
+ vsync-len = <12>;
+ hsync-active = <0>;
+ vsync-active = <0>;
+ de-active = <0>;
+ pixelclk-active = <1>;
+ };
+ };
+ };
+};
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 02/10] video: stm32: stm32_ltdc: update debug log
Replace macro debug by pr_error, pr_warn or pr_info.
Signed-off-by: yannick fertre
---
drivers/video/stm32/stm32_ltdc.c | 62
1 file changed, 31 insertions(+), 31 deletions(-)
diff --git a/drivers/video/stm32/stm32_ltdc.c b/drivers/video/stm32/stm32_ltdc.c
index bd9c0de..e95f35c 100644
--- a/drivers/video/stm32/stm32_ltdc.c
+++ b/drivers/video/stm32/stm32_ltdc.c
@@ -176,13 +176,13 @@ static u32 stm32_ltdc_get_pixel_format(enum
video_log2_bpp l2bpp)
case VIDEO_BPP2:
case VIDEO_BPP4:
default:
- debug("%s: warning %dbpp not supported yet, %dbpp instead\n",
- __func__, VNBITS(l2bpp), VNBITS(VIDEO_BPP16));
+ pr_warn("%s: warning %dbpp not supported yet, %dbpp instead\n",
+ __func__, VNBITS(l2bpp), VNBITS(VIDEO_BPP16));
pf = PF_RGB565;
break;
}
- debug("%s: %d bpp -> ltdc pf %d\n", __func__, VNBITS(l2bpp), pf);
+ pr_info("%s: %d bpp -> ltdc pf %d\n", __func__, VNBITS(l2bpp), pf);
return (u32)pf;
}
@@ -249,7 +249,7 @@ static void stm32_ltdc_set_mode(struct stm32_ltdc_priv
*priv,
/* Signal polarities */
val = 0;
- debug("%s: timing->flags 0x%08x\n", __func__, timings->flags);
+ pr_info("%s: timing->flags 0x%08x\n", __func__, timings->flags);
if (timings->flags & DISPLAY_FLAGS_HSYNC_HIGH)
val |= GCR_HSPOL;
if (timings->flags & DISPLAY_FLAGS_VSYNC_HIGH)
@@ -343,26 +343,26 @@ static int stm32_ltdc_probe(struct udevice *dev)
priv->regs = (void *)dev_read_addr(dev);
if ((fdt_addr_t)priv->regs == FDT_ADDR_T_NONE) {
- debug("%s: ltdc dt register address error\n", __func__);
+ pr_err("%s: ltdc dt register address error\n", __func__);
return -EINVAL;
}
ret = clk_get_by_index(dev, 0, &pclk);
if (ret) {
- debug("%s: peripheral clock get error %d\n", __func__, ret);
+ pr_err("%s: peripheral clock get error %d\n", __func__, ret);
return ret;
}
ret = clk_enable(&pclk);
if (ret) {
- debug("%s: peripheral clock enable error %d\n",
- __func__, ret);
+ pr_err("%s: peripheral clock enable error %d\n",
+ __func__, ret);
return ret;
}
ret = reset_get_by_index(dev, 0, &rst);
if (ret) {
- debug("%s: missing ltdc hardware reset\n", __func__);
+ pr_err("%s: missing ltdc hardware reset\n", __func__);
return -ENODEV;
}
@@ -372,41 +372,40 @@ static int stm32_ltdc_probe(struct udevice *dev)
#ifdef CONFIG_VIDEO_BRIDGE
ret = uclass_get_device(UCLASS_VIDEO_BRIDGE, 0, &bridge);
if (ret) {
- debug("%s: No video bridge, or no backlight on bridge\n",
- __func__);
+ pr_info("%s: No video bridge, or no backlight on bridge\n",
+ __func__);
}
if (bridge) {
ret = video_bridge_attach(bridge);
if (ret) {
- debug("%s: fail to attach bridge\n", __func__);
+ pr_err("%s: fail to attach bridge\n", __func__);
return ret;
}
}
#endif
ret = uclass_first_device(UCLASS_PANEL, &panel);
if (ret) {
- debug("%s: panel device error %d\n", __func__, ret);
+ pr_err("%s: panel device error %d\n", __func__, ret);
return ret;
}
ret = fdtdec_decode_display_timing(gd->fdt_blob, dev_of_offset(panel),
0, &timings);
if (ret) {
- debug("%s: decode display timing error %d\n",
- __func__, ret);
+ pr_err("%s: decode display timing error %d\n", __func__, ret);
return ret;
}
rate = clk_set_rate(&pclk, timings.pixelclock.typ);
if (rate < 0) {
- debug("%s: fail to set pixel clock %d hz %d hz\n",
- __func__, timings.pixelclock.typ, rate);
+ pr_err("%s: fail to set pixel clock %d hz %d hz\n",
+ __func__, timings.pixelclock.typ, rate);
return rate;
}
- debug("%s: Set pixel clock req %d hz get %d hz\n", __func__,
- timings.pixelclock.typ, rate);
+ pr_info("%s: Set pixel clock req %d hz get %d hz\n", __func__,
+ timings.pixelclock.typ, rate);
/* TODO Below parameters are hard-coded for the moment... */
priv->l2bpp = VIDEO_BPP16;
@@ -417,12 +416,12 @@ static int stm32_ltdc_probe(struct udevice *dev)
priv->crop_h = timings.vactive.typ;
priv->alpha = 0xFF;
- debug("%s: %dx%d %dbpp frame buffer at 0x%lx\n"
[PATCH v2 10/10] board: Add STM32F769 SoC, discovery board support
Signed-off-by: yannick fertre --- configs/stm32f769-disco_defconfig | 63 +++ 1 file changed, 63 insertions(+) create mode 100644 configs/stm32f769-disco_defconfig diff --git a/configs/stm32f769-disco_defconfig b/configs/stm32f769-disco_defconfig new file mode 100644 index 000..ac34076 --- /dev/null +++ b/configs/stm32f769-disco_defconfig @@ -0,0 +1,63 @@ +CONFIG_ARM=y +CONFIG_STM32=y +CONFIG_SYS_MALLOC_F_LEN=0xC00 +CONFIG_STM32F7=y +CONFIG_TARGET_STM32F746_DISCO=y +CONFIG_DEFAULT_DEVICE_TREE="stm32f769-disco" +CONFIG_BOOTDELAY=3 +CONFIG_USE_BOOTARGS=y +CONFIG_BOOTARGS="console=ttyS0,115200 earlyprintk consoleblank=0 ignore_loglevel" +# CONFIG_DISPLAY_CPUINFO is not set +# CONFIG_DISPLAY_BOARDINFO is not set +CONFIG_BOARD_EARLY_INIT_F=y +CONFIG_HUSH_PARSER=y +CONFIG_SYS_PROMPT="U-Boot > " +CONFIG_AUTOBOOT_KEYED=y +CONFIG_AUTOBOOT_PROMPT="Hit SPACE in %d seconds to stop autoboot.\n" +CONFIG_AUTOBOOT_STOP_STR=" " +CONFIG_CMD_BOOTZ=y +# CONFIG_CMD_FPGA is not set +CONFIG_CMD_GPT=y +# CONFIG_RANDOM_UUID is not set +CONFIG_CMD_MMC=y +CONFIG_CMD_SF=y +# CONFIG_CMD_SETEXPR is not set +CONFIG_CMD_DHCP=y +CONFIG_CMD_MII=y +CONFIG_CMD_PING=y +CONFIG_CMD_SNTP=y +CONFIG_CMD_DNS=y +CONFIG_CMD_LINK_LOCAL=y +CONFIG_CMD_BMP=y +CONFIG_CMD_TIMER=y +CONFIG_CMD_EXT2=y +CONFIG_CMD_EXT4=y +CONFIG_CMD_FAT=y +CONFIG_CMD_FS_GENERIC=y +# CONFIG_DOS_PARTITION is not set +CONFIG_OF_CONTROL=y +CONFIG_NET_RANDOM_ETHADDR=y +CONFIG_NETCONSOLE=y +# CONFIG_BLK is not set +CONFIG_DM_MMC=y +# CONFIG_SPL_DM_MMC is not set +CONFIG_ARM_PL180_MMCI=y +CONFIG_MTD=y +CONFIG_MTD_NOR_FLASH=y +CONFIG_DM_SPI_FLASH=y +CONFIG_SPI_FLASH=y +CONFIG_SPI_FLASH_STMICRO=y +CONFIG_DM_ETH=y +CONFIG_ETH_DESIGNWARE=y +# CONFIG_PINCTRL_FULL is not set +CONFIG_DM_SPI=y +CONFIG_STM32_QSPI=y +CONFIG_DM_VIDEO=y +CONFIG_BACKLIGHT_GPIO=y +CONFIG_VIDEO_LCD_ORISETECH_OTM8009A=y +CONFIG_VIDEO_STM32=y +CONFIG_VIDEO_STM32_DSI=y +CONFIG_VIDEO_STM32_MAX_XRES=480 +CONFIG_VIDEO_STM32_MAX_YRES=800 +CONFIG_OF_LIBFDT_OVERLAY=y +# CONFIG_EFI_LOADER is not set -- 1.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 05/10] video: add MIPI DSI host controller bridge
Add a Synopsys Designware MIPI DSI host bridge driver, based on the
Rockchip version from rockchip/dw-mipi-dsi.c with phy & bridge APIs.
Signed-off-by: yannick fertre
---
drivers/video/Kconfig | 9 +
drivers/video/Makefile | 1 +
drivers/video/dw_mipi_dsi.c | 822
include/dw_mipi_dsi.h | 32 ++
4 files changed, 864 insertions(+)
create mode 100644 drivers/video/dw_mipi_dsi.c
create mode 100644 include/dw_mipi_dsi.h
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index b5fc535..0f641d7 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -657,6 +657,15 @@ config VIDEO_DW_HDMI
rather requires a SoC-specific glue driver to call it), it
can not be enabled from the configuration menu.
+config VIDEO_DW_MIPI_DSI
+ bool
+ help
+ Enables the common driver code for the Designware MIPI DSI
+ block found in SoCs from various vendors.
+ As this does not provide any functionality by itself (but
+ rather requires a SoC-specific glue driver to call it), it
+ can not be enabled from the configuration menu.
+
config VIDEO_SIMPLE
bool "Simple display driver for preconfigured display"
help
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index 65002af..50be569 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -53,6 +53,7 @@ obj-$(CONFIG_FORMIKE) += formike.o
obj-$(CONFIG_LG4573) += lg4573.o
obj-$(CONFIG_AM335X_LCD) += am335x-fb.o
obj-$(CONFIG_VIDEO_DW_HDMI) += dw_hdmi.o
+obj-$(CONFIG_VIDEO_DW_MIPI_DSI) += dw_mipi_dsi.o
obj-${CONFIG_VIDEO_MIPI_DSI} += mipi_display.o
obj-$(CONFIG_VIDEO_SIMPLE) += simplefb.o
obj-${CONFIG_VIDEO_TEGRA124} += tegra124/
diff --git a/drivers/video/dw_mipi_dsi.c b/drivers/video/dw_mipi_dsi.c
new file mode 100644
index 000..d7bd92d
--- /dev/null
+++ b/drivers/video/dw_mipi_dsi.c
@@ -0,0 +1,822 @@
+/*
+ * Copyright (C) 2016, Fuzhou Rockchip Electronics Co., Ltd
+ * Copyright (C) 2018, STMicroelectronics - All Rights Reserved
+ * Author(s): Philippe Cornu for STMicroelectronics.
+ * Yannick Fertre for STMicroelectronics.
+ *
+ * Modified by Yannick Fertre
+ * This generic Synopsys DesignWare MIPI DSI host driver is based on the
+ * bridge synopsys from drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c (kernel
+ * linux).
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define HWVER_131 0x31333100 /* IP version 1.31 */
+
+#define DSI_VERSION0x00
+#define VERSIONGENMASK(31, 8)
+
+#define DSI_PWR_UP 0x04
+#define RESET 0
+#define POWERUPBIT(0)
+
+#define DSI_CLKMGR_CFG 0x08
+#define TO_CLK_DIVISION(div) (((div) & 0xff) << 8)
+#define TX_ESC_CLK_DIVISION(div) ((div) & 0xff)
+
+#define DSI_DPI_VCID 0x0c
+#define DPI_VCID(vcid) ((vcid) & 0x3)
+
+#define DSI_DPI_COLOR_CODING 0x10
+#define LOOSELY18_EN BIT(8)
+#define DPI_COLOR_CODING_16BIT_1 0x0
+#define DPI_COLOR_CODING_16BIT_2 0x1
+#define DPI_COLOR_CODING_16BIT_3 0x2
+#define DPI_COLOR_CODING_18BIT_1 0x3
+#define DPI_COLOR_CODING_18BIT_2 0x4
+#define DPI_COLOR_CODING_24BIT 0x5
+
+#define DSI_DPI_CFG_POL0x14
+#define COLORM_ACTIVE_LOW BIT(4)
+#define SHUTD_ACTIVE_LOW BIT(3)
+#define HSYNC_ACTIVE_LOW BIT(2)
+#define VSYNC_ACTIVE_LOW BIT(1)
+#define DATAEN_ACTIVE_LOW BIT(0)
+
+#define DSI_DPI_LP_CMD_TIM 0x18
+#define OUTVACT_LPCMD_TIME(p) (((p) & 0xff) << 16)
+#define INVACT_LPCMD_TIME(p) ((p) & 0xff)
+
+#define DSI_DBI_VCID 0x1c
+#define DSI_DBI_CFG0x20
+#define DSI_DBI_PARTITIONING_EN0x24
+#define DSI_DBI_CMDSIZE0x28
+
+#define DSI_PCKHDL_CFG 0x2c
+#define CRC_RX_EN BIT(4)
+#define ECC_RX_EN BIT(3)
+#define BTA_EN BIT(2)
+#define EOTP_RX_EN BIT(1)
+#define EOTP_TX_EN BIT(0)
+
+#define DSI_GEN_VCID 0x30
+
+#define DSI_MODE_CFG 0x34
+#define ENABLE_VIDEO_MODE 0
+#define ENABLE_CMD_MODEBIT(0)
+
+#define DSI_VID_MODE_CFG 0x38
+#define ENABLE_LOW_POWER (0x3f << 8)
+#define ENABLE_LOW_POWER_MASK (0x3f << 8)
+#define VID_MODE_TYPE_NON_BURST_SYNC_PULSES0x0
+#define VID_MODE_TYPE_NON_BURST_SYNC_EVENTS0x1
+#define VID_MODE_TYPE_BURST0x2
+#define VID_MODE_TYPE_MASK 0x3
+
+#define D
Re: [PATCH] drm/vc4: Ignore alpha on primary plane
On Fri, Mar 2, 2018 at 4:21 PM, Ville Syrjälä wrote: > On Fri, Mar 02, 2018 at 04:06:58PM +0100, Stefan Schake wrote: >> Hey Ville, >> >> On Fri, Mar 2, 2018 at 3:43 PM, Ville Syrjälä >> wrote: >> > On Fri, Mar 02, 2018 at 04:39:22PM +0200, Ville Syrjälä wrote: >> >> If you want the plane to always be opaque you shouldn't expose any >> >> formats with alpha. >> >> >> >> Also what happens if one disables the primary plane? Or does the driver >> >> not allow that? >> > >> > Or just makes the plane not cover the entire screen? >> >> We've exposed alpha formats in the past so disabling that now would break >> userspace, certainly Android that chooses alpha-everything. > > So it refuses to even run on hardware that can't do per-pixel alpha on > the primary plane? Well since we have no real primary plane we'd have to remove support from every plane or add elaborate logic to atomic check that detects and rejects a configuration that has pixels blending from nothing, which presumably is what triggers the display artifacts. >> The VC4 HVS >> has no fixed planes so I'll acknowledge that the concept of a primary plane >> is somewhat dubious and userspace could disable it or make it not cover the >> entire screen, making this ineffective. >> >> But then ultimately there doesn't seem to be a standard for what the display >> is supposed to be if you have transparent pixels with no plane to blend to >> below. > > The standard is black. IMO it's a driver bug if it fails to do that. Then to be sure we should always enable the background fill. Maybe Eric can clarify what the cost for this is, all I have to go on there is the comment on the register set. Thanks, Stefan ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Patch 2/4] dt-bindings: display/ti: Add plane binding to dispc node
Add 'plane' child node to generic DISPC node as an optional
property.
Signed-off-by: Benoit Parrot
---
.../devicetree/bindings/display/ti/ti,omap-dss.txt | 63 ++
1 file changed, 63 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/ti/ti,omap-dss.txt
b/Documentation/devicetree/bindings/display/ti/ti,omap-dss.txt
index 249e588d7865..cb101525b805 100644
--- a/Documentation/devicetree/bindings/display/ti/ti,omap-dss.txt
+++ b/Documentation/devicetree/bindings/display/ti/ti,omap-dss.txt
@@ -27,6 +27,34 @@ DISPC
Optional properties:
- max-memory-bandwidth: Input memory (from main memory to dispc) bandwidth
limit
in bytes per second
+- plane: Child node(s) which defines which logical plane are available to
+ the system. If at least one plane child node is defined then
+ only planes defined by these nodes will be available to the system.
+ Plane nodes must be sequential starting with reg = <0> as DT parsing
+ will stop on the first missing numbered node.
+ This means if plane #1 is defined but plane #0 is not then it will
+ be as if none of the plane nodes were defined.
+
+ Each plane node contains the following properties:
+ Required properties:
+ - reg: Used to number the logical plane
+ - hw-planes: One or two HW plane number(s).
+When 2 numbers are present this indicates a virtual plane
+composed of two physical planes intended to be used
+when the display is larger then the capacity of a
+single plane i.e. wider than 2048 pixels.
+The first number in the pair will dictate the capabilities
+of the virtual plane. This means that for proper
+operation the virtual plane should be composed of HW
+planes of the same capabilities.
+If GFX plane is used in a virtual plane it should be
+specified first, otherwise unexpected behavior would
+be encountered.
+ Optional property:
+ - hw-crtcs: One or more HW crtc number(s).
+Describe the list of CRTCs on which this plane is
+available. If this node is not present then the
+plane will be available on all available CRTCs.
Video Ports
---
@@ -216,3 +244,38 @@ OMAP HDMI --(HDMI)--> TPD12S015 --(HDMI)--> HDMI Connector
};
};
};
+
+A short example on how to define a virtual plane configuration
+to enable wide display support.
+Here we define:
+- plane#0 to be the HW plane #0 (i.e. GFX plane)
+ only available on crtc #0
+- plane#1 to be a virtual wide plane composed of HW plane #1 and #2
+ (i.e. VID1 & VID2) available on crtc #0 & #1
+- plane#2 to be the HW plane #3 (i.e. VID3 plane)
+ only available on crtc #0
+
+&dss {
+dispc@58001000 {
+#address-cells = <1>;
+#size-cells = <0>;
+
+plane@0 {
+reg = <0>;
+hw-planes = <0>;
+hw-crtcs = <0>;
+};
+
+plane@1 {
+reg = <1>;
+hw-planes = <1 2>;
+hw-crtcs = <0 1>;
+};
+
+plane@2 {
+reg = <2>;
+hw-planes = <3>;
+hw-crtcs = <0>;
+};
+};
+};
--
2.9.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Patch 4/4] drm/omap: Add virtual plane support to omap_plane
Add virtual plane support by adding an array to contain
all of the actual plane_id a "omap_plane" correspond to.
When at least one 'plane' child node is present in DT then
omap_plane_init will only used the plane described in DT.
Some of these nodes may be a virtual plane if they are defined
as two physical planes.
Planes can also be associated with various crtcs independently.
Therefore we can restrict the use of virtual plane to specific
CRTC/video port if need be, if crtc_mask is not specified then
the plane will be available to all available crtcs.
Physical plane which are not described will essentially be hidden
from the driver.
If no 'plane' child node exist then the existing plane
allocation will take place.
Signed-off-by: Benoit Parrot
---
drivers/gpu/drm/omapdrm/omap_drv.c | 18 +++--
drivers/gpu/drm/omapdrm/omap_fb.c| 66 +++--
drivers/gpu/drm/omapdrm/omap_fb.h| 4 +-
drivers/gpu/drm/omapdrm/omap_plane.c | 139 +--
drivers/gpu/drm/omapdrm/omap_plane.h | 3 +-
5 files changed, 162 insertions(+), 68 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c
b/drivers/gpu/drm/omapdrm/omap_drv.c
index dd68b2556f5b..73796364a592 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.c
+++ b/drivers/gpu/drm/omapdrm/omap_drv.c
@@ -188,10 +188,9 @@ static int omap_connect_dssdevs(void)
return r;
}
-static int omap_modeset_init_properties(struct drm_device *dev)
+static int omap_modeset_init_properties(struct drm_device *dev, u32 num_planes)
{
struct omap_drm_private *priv = dev->dev_private;
- unsigned int num_planes = priv->dispc_ops->get_num_ovls();
priv->zorder_prop = drm_property_create_range(dev, 0, "zorder", 0,
num_planes - 1);
@@ -210,10 +209,19 @@ static int omap_modeset_init(struct drm_device *dev)
int num_crtcs, crtc_idx, plane_idx;
int ret;
u32 plane_crtc_mask;
+ struct dispc_plane_mappings plane_mappings = {0};
drm_mode_config_init(dev);
- ret = omap_modeset_init_properties(dev);
+ ret = priv->dispc_ops->get_plane_mapping(&plane_mappings);
+ if (ret < 0)
+ return ret;
+
+ /* use plane mappings info */
+ if (plane_mappings.num_planes)
+ num_ovls = plane_mappings.num_planes;
+
+ ret = omap_modeset_init_properties(dev, num_ovls);
if (ret < 0)
return ret;
@@ -266,7 +274,7 @@ static int omap_modeset_init(struct drm_device *dev)
return -ENOMEM;
plane = omap_plane_init(dev, plane_idx, DRM_PLANE_TYPE_PRIMARY,
- plane_crtc_mask);
+ plane_crtc_mask, &plane_mappings);
if (IS_ERR(plane))
return PTR_ERR(plane);
@@ -296,7 +304,7 @@ static int omap_modeset_init(struct drm_device *dev)
return -EINVAL;
plane = omap_plane_init(dev, plane_idx, DRM_PLANE_TYPE_OVERLAY,
- plane_crtc_mask);
+ plane_crtc_mask, &plane_mappings);
if (IS_ERR(plane))
return PTR_ERR(plane);
diff --git a/drivers/gpu/drm/omapdrm/omap_fb.c
b/drivers/gpu/drm/omapdrm/omap_fb.c
index b2539a90e1a4..80b29b7f5696 100644
--- a/drivers/gpu/drm/omapdrm/omap_fb.c
+++ b/drivers/gpu/drm/omapdrm/omap_fb.c
@@ -153,25 +153,27 @@ static uint32_t drm_rotation_to_tiler(unsigned int
drm_rot)
/* update ovl info for scanout, handles cases of multi-planar fb's, etc.
*/
void omap_framebuffer_update_scanout(struct drm_framebuffer *fb,
- struct drm_plane_state *state, struct omap_overlay_info *info)
+ struct drm_plane_state *state,
+ struct omap_overlay_info *main_info,
+ struct omap_overlay_info *aux_info)
{
struct omap_framebuffer *omap_fb = to_omap_framebuffer(fb);
const struct drm_format_info *format = omap_fb->format;
struct plane *plane = &omap_fb->planes[0];
uint32_t x, y, orient = 0;
- info->fourcc = fb->format->format;
+ main_info->fourcc = fb->format->format;
- info->pos_x = state->crtc_x;
- info->pos_y = state->crtc_y;
- info->out_width = state->crtc_w;
- info->out_height = state->crtc_h;
- info->width = state->src_w >> 16;
- info->height = state->src_h >> 16;
+ main_info->pos_x = state->crtc_x;
+ main_info->pos_y = state->crtc_y;
+ main_info->out_width = state->crtc_w;
+ main_info->out_height = state->crtc_h;
+ main_info->width = state->src_w >> 16;
+ main_info->height = state->src_h >> 16;
/* DSS driver wants the w & h in rotated orientation */
if (drm_rotation_90_or_270(state->rotation))
- swap(info->width, info->height);
+
Re: [PATCH] drm/vc4: Ignore alpha on primary plane
On Fri, Mar 02, 2018 at 04:48:03PM +0100, Stefan Schake wrote: > On Fri, Mar 2, 2018 at 4:21 PM, Ville Syrjälä > wrote: > > On Fri, Mar 02, 2018 at 04:06:58PM +0100, Stefan Schake wrote: > >> Hey Ville, > >> > >> On Fri, Mar 2, 2018 at 3:43 PM, Ville Syrjälä > >> wrote: > >> > On Fri, Mar 02, 2018 at 04:39:22PM +0200, Ville Syrjälä wrote: > >> >> If you want the plane to always be opaque you shouldn't expose any > >> >> formats with alpha. > >> >> > >> >> Also what happens if one disables the primary plane? Or does the driver > >> >> not allow that? > >> > > >> > Or just makes the plane not cover the entire screen? > >> > >> We've exposed alpha formats in the past so disabling that now would break > >> userspace, certainly Android that chooses alpha-everything. > > > > So it refuses to even run on hardware that can't do per-pixel alpha on > > the primary plane? > > Well since we have no real primary plane we'd have to remove support from > every plane or add elaborate logic to atomic check that detects and rejects > a configuration that has pixels blending from nothing, which presumably is > what triggers the display artifacts. > > >> The VC4 HVS > >> has no fixed planes so I'll acknowledge that the concept of a primary plane > >> is somewhat dubious and userspace could disable it or make it not cover the > >> entire screen, making this ineffective. > >> > >> But then ultimately there doesn't seem to be a standard for what the > >> display > >> is supposed to be if you have transparent pixels with no plane to blend to > >> below. > > > > The standard is black. IMO it's a driver bug if it fails to do that. > > Then to be sure we should always enable the background fill. Maybe Eric can > clarify what the cost for this is, all I have to go on there is the comment > on the register set. Yeah, that sounds like the correct thing to do. -- Ville Syrjälä Intel OTC ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 03/14] iommu: Create a base struct for io_mm
On Fri, Mar 02, 2018 at 12:25:48PM +, Jean-Philippe Brucker wrote:
> Hi Jordan,
>
> Thank you for this, SMMUv3 and virtio-iommu need these SVA patches as well.
>
> On 21/02/18 22:59, Jordan Crouse wrote:
> [...]> diff --git a/include/linux/iommu.h b/include/linux/iommu.h
> > index e2c49e583d8d..e998389cf195 100644
> > --- a/include/linux/iommu.h
> > +++ b/include/linux/iommu.h
> > @@ -110,8 +110,17 @@ struct iommu_domain {
> > struct list_head mm_list;
> > };
> >
> > +enum iommu_io_type {
> > + IO_TYPE_MM,
> > +};
> > +
> > +struct io_base {
> > + int type;
> > + int pasid;
> > +};
>
> "io_base" is a bit vague. I'm bad at naming so my opinion doesn't hold
> much water, but I'd rather this be something like "io_mm_base". When I
> initially toyed with the idea I intended to keep io_mm as parent structure
> and have "private" and "shared" sub-structures. Even if private PASIDs
> don't rely on the kernel mm subsystem, this structure would still
> represent an I/O mm of sorts, with a pgd and pgtable info.
I'm also bad at naming but I don't mind changing it. io_mm_base seems okay to me
unless somebody has a better idea. I also like the terms "private" and
"shared". I'm going to start adopting those where it makes sense.
Jordan
>
> > +
> > struct io_mm {
> > - int pasid;
> > + struct io_base base;
> > struct list_headdevices;
> > struct kref kref;
> > #if defined(CONFIG_MMU_NOTIFIER)
> >
>
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 04/14] iommu: sva: Add support for pasid allocation
On Fri, Mar 02, 2018 at 12:27:58PM +, Jean-Philippe Brucker wrote:
> On 21/02/18 22:59, Jordan Crouse wrote:
> [...]
> > +int iommu_sva_alloc_pasid(struct iommu_domain *domain, struct device *dev)
> > +{
> > + int ret, pasid;
> > + struct io_pasid *io_pasid;
> > +
> > + if (!domain->ops->pasid_alloc || !domain->ops->pasid_free)
> > + return -ENODEV;
> > +
> > + io_pasid = kzalloc(sizeof(*io_pasid), GFP_KERNEL);
> > + if (!io_pasid)
> > + return -ENOMEM;
> > +
> > + io_pasid->domain = domain;
> > + io_pasid->base.type = IO_TYPE_PASID;
> > +
> > + idr_preload(GFP_KERNEL);
> > + spin_lock(&iommu_sva_lock);
> > + pasid = idr_alloc_cyclic(&iommu_pasid_idr, &io_pasid->base,
> > + 1, (1 << 31), GFP_ATOMIC);
>
> To be usable by other IOMMUs, this should restrict the PASID range to what
> the IOMMU and the device support like io_mm_alloc(). In your case 31 bits,
> but with PCI PASID it depends on the PASID capability and the SMMU
> SubstreamID range.
>
> For this reason I think device drivers should call iommu_sva_device_init()
> once, even for the alloc_pasid() API. For SMMUv2 I guess it will be a NOP,
> but other IOMMUs will allocate PASID tables and enable features in the
> device. In addition, knowing that all users of the API call
> iommu_sva_device_init()/shutdown() could allow us to allocate and enable
> stuff lazily in the future.
>
> It would also allow a given device driver to use both
> iommu_sva_pasid_alloc() and iommu_sva_bind() at the same time. So that the
> driver can assigns contexts to userspace and still use some of them for
> management.
No problem.
> [...]
> > +int iommu_sva_map(int pasid, unsigned long iova,
> > + phys_addr_t paddr, size_t size, int prot)
>
> It would be nice to factor iommu_map(), since this logic for map, map_sg
> and unmap should be the same regardless of the PASID argument.
>
> For example
> - iommu_sva_map(domain, pasid, ...)
> - iommu_map(domain, ...)
>
> both call
> - __iommu_map(domain, pasid, ...)
>
> which calls either
> - ops->map(domain, ...)
> - ops->sva_map(domain, pasid, ...)
Agree. I was kind of annoyed at the code duplication - this would be a good way
to handle it.
> [...]
> > @@ -347,6 +353,15 @@ struct iommu_ops {
> > int (*page_response)(struct iommu_domain *domain, struct device *dev,
> > struct page_response_msg *msg);
> >
> > + int (*pasid_alloc)(struct iommu_domain *domain, struct device *dev,
> > + int pasid);
> > + int (*sva_map)(struct iommu_domain *domain, int pasid,
> > + unsigned long iova, phys_addr_t paddr, size_t size,
> > + int prot);
> > + size_t (*sva_unmap)(struct iommu_domain *domain, int pasid,
> > + unsigned long iova, size_t size);
> > + void (*pasid_free)(struct iommu_domain *domain, int pasid);
> > +
>
> Hmm, now IOMMU has the following ops:
>
> * mm_alloc(): allocates a shared mm structure
> * mm_attach(): writes the entry in the PASID table
> * mm_detach(): removes the entry from the PASID table and invalidates it
> * mm_free(): free shared mm
> * pasid_alloc(): allocates a pasid structure (which I usually call
> "private mm") and write the entry in the PASID table (or call
> install_pasid() for SMMUv2)
> * pasid_free(): remove from the PASID table (or call remove_pasid()) and
> free the pasid structure.
>
> Splitting mm_alloc and mm_attach is necessary because the io_mm in my case
> can be shared between devices (allocated once, attached multiple times).
> In your case a PASID is private to one device so only one callback is
> needed. However mm_alloc+mm_attach will do roughly the same as
> pasid_alloc, so to reduce redundancy in iommu_ops, maybe we could reuse
> mm_alloc and mm_attach for the private PASID case?
Okay - let me bang on it and see what we can clean up. Thanks for the review.
Jordan
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/sun4i: add lvds mode_valid function
Hi,
Il 02/03/2018 15:37, Maxime Ripard ha scritto:
On Fri, Mar 02, 2018 at 12:42:14PM +0100, Giulio Benetti wrote:
Hi,
Il 01/03/2018 10:57, Maxime Ripard ha scritto:
On Wed, Feb 28, 2018 at 06:53:52PM +0100, Giulio Benetti wrote:
static struct drm_connector_helper_funcs sun4i_lvds_con_helper_funcs = {
.get_modes = sun4i_lvds_get_modes,
+ .mode_valid = sun4i_lvds_mode_valid,
};
This should be on the encoder, not the connector.
I've seen it is bound to connector in rgb and to encoder in hdmi.
Is it correct rgb mode_valid under connector funcs?
Otherwise I send a patch also for that one.
This would need to be fixed as well. Bridges attach to encoder, not
connectors, so if you ever have a bridge connected to the RGB output
(like on the A13-Olinuxino), mode_valid isn't called at the moment.
Ok, I will do the same for rgb and submit a patchset,
need some time to test both lvds and rgb.
--
Giulio Benetti
CTO
MICRONOVA SRL
Sede: Via A. Niedda 3 - 35010 Vigonza (PD)
Tel. 049/8931563 - Fax 049/8931346
Cod.Fiscale - P.IVA 02663420285
Capitale Sociale € 26.000 i.v.
Iscritta al Reg. Imprese di Padova N. 02663420285
Numero R.E.A. 258642
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/vc4: Ignore alpha on primary plane
Ville Syrjälä writes: > On Fri, Mar 02, 2018 at 04:06:58PM +0100, Stefan Schake wrote: >> Hey Ville, >> >> On Fri, Mar 2, 2018 at 3:43 PM, Ville Syrjälä >> wrote: >> > On Fri, Mar 02, 2018 at 04:39:22PM +0200, Ville Syrjälä wrote: >> >> If you want the plane to always be opaque you shouldn't expose any >> >> formats with alpha. >> >> >> >> Also what happens if one disables the primary plane? Or does the driver >> >> not allow that? >> > >> > Or just makes the plane not cover the entire screen? >> >> We've exposed alpha formats in the past so disabling that now would break >> userspace, certainly Android that chooses alpha-everything. > > So it refuses to even run on hardware that can't do per-pixel alpha on > the primary plane? > >> The VC4 HVS >> has no fixed planes so I'll acknowledge that the concept of a primary plane >> is somewhat dubious and userspace could disable it or make it not cover the >> entire screen, making this ineffective. >> >> But then ultimately there doesn't seem to be a standard for what the display >> is supposed to be if you have transparent pixels with no plane to blend to >> below. > > The standard is black. IMO it's a driver bug if it fails to do that. If the plane is premultiplied (isn't that what DRM planes are supposed to be? I can't find any docs), then blending against black is the same as not doing any blending at all. signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 105046] Screen resolution reset to 1368x768 when turning monitor off
https://bugs.freedesktop.org/show_bug.cgi?id=105046
--- Comment #10 from Michael Zapf ---
It seems to be related to EDID, as I see it.
Once I turn off the display, I lose the EDID information.
Before:
# find /sys -name edid -exec echo {} \; -exec od -tx1 -Ax {} \;
/sys/devices/pci:00/:00:01.0/:01:00.0/drm/card0/card0-DVI-D-1/edid
00
/sys/devices/pci:00/:00:01.0/:01:00.0/drm/card0/card0-DP-2/edid
00
/sys/devices/pci:00/:00:01.0/:01:00.0/drm/card0/card0-HDMI-A-2/edid
00 00 ff ff ff ff ff ff 00 41 2f 27 10 01 01 01 01
10 00 19 01 03 80 36 23 78 ee ce 50 a3 54 4c 99 26
20 0f 50 54 a5 6b 80 81 40 a9 00 a9 40 b3 00 d1 00
30 01 01 01 01 01 01 28 3c 80 a0 70 b0 23 40 30 20
40 36 00 22 60 21 00 00 1a 00 00 00 fc 00 56 53 58
50 2d 33 33 30 0a 20 20 20 20 20 00 00 00 fd 00 30
60 55 1e 46 11 00 0a 20 20 20 20 20 20 00 00 00 ff
70 00 50 4c 43 39 33 33 30 31 34 47 0a 20 20 01 a6
80 02 03 34 71 4b 01 02 04 85 06 10 11 13 14 15 1f
90 38 09 7f 07 0f 7f 07 15 07 50 3e 06 c0 49 7f 00
a0 57 06 00 5f 7e 01 67 7e 00 83 4f 00 00 66 03 0c
b0 00 11 00 80 01 1d 80 18 71 1c 16 20 58 2c 25 00
c0 06 44 21 00 00 9e 01 1d 80 d0 72 1c 16 20 10 2c
d0 25 80 06 44 21 00 00 9e 01 1d 00 72 51 d0 1e 20
e0 6e 28 55 00 06 44 21 00 00 1e 01 1d 00 bc 52 d0
f0 1e 20 b8 28 55 40 06 44 21 00 00 1e 00 00 00 8f
000100
/sys/devices/pci:00/:00:01.0/:01:00.0/drm/card0/card0-DP-1/edid
00
/sys/devices/pci:00/:00:01.0/:01:00.0/drm/card0/card0-HDMI-A-1/edid
00
Turn off, turn on again:
# find /sys -name edid -exec echo {} \; -exec od -tx1 -Ax {} \;
/sys/devices/pci:00/:00:01.0/:01:00.0/drm/card0/card0-DVI-D-1/edid
00
/sys/devices/pci:00/:00:01.0/:01:00.0/drm/card0/card0-DP-2/edid
00
/sys/devices/pci:00/:00:01.0/:01:00.0/drm/card0/card0-HDMI-A-2/edid
00
/sys/devices/pci:00/:00:01.0/:01:00.0/drm/card0/card0-DP-1/edid
00
/sys/devices/pci:00/:00:01.0/:01:00.0/drm/card0/card0-HDMI-A-1/edid
00
When I continue to turn it off and on again, EDID does not reappear. However,
when I reboot, it is there again. How does my monitor know that my PC has been
rebooted?
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 05/10] pwm: add PWM mode to pwm_config()
On 28.02.2018 22:04, Jani Nikula wrote:
> On Wed, 28 Feb 2018, Thierry Reding wrote:
>> Anyone that needs something other than normal mode should use the new
>> atomic PWM API.
>
> At the risk of revealing my true ignorance, what is the new atomic PWM
> API? Where? Examples of how one would convert old code over to the new
> API?
As far as I know, the old PWM core code uses config(), set_polarity(),
enable(), disable() methods of driver, registered as pwm_ops:
struct pwm_ops {
int (*request)(struct pwm_chip *chip, struct pwm_device *pwm);
void (*free)(struct pwm_chip *chip, struct pwm_device *pwm);
int (*config)(struct pwm_chip *chip, struct pwm_device *pwm,
int duty_ns, int period_ns);
int (*set_polarity)(struct pwm_chip *chip, struct pwm_device *pwm,
enum pwm_polarity polarity);
int (*capture)(struct pwm_chip *chip, struct pwm_device *pwm,
struct pwm_capture *result, unsigned long timeout);
int (*enable)(struct pwm_chip *chip, struct pwm_device *pwm);
void (*disable)(struct pwm_chip *chip, struct pwm_device *pwm);
int (*apply)(struct pwm_chip *chip, struct pwm_device *pwm,
struct pwm_state *state);
void (*get_state)(struct pwm_chip *chip, struct pwm_device *pwm,
struct pwm_state *state);
#ifdef CONFIG_DEBUG_FS
void (*dbg_show)(struct pwm_chip *chip, struct seq_file *s);
#endif
struct module *owner;
};
to do settings on hardware. In order to so settings on a PWM the users
should have been follow the below steps:
->config()
->set_polarity()
->enable()
Moreover, if the PWM was previously enabled it should have been first
disable and then to follow the above steps in order to apply a new settings
on hardware.
The driver should have been provide, at probe, all the above function:
->config(), ->set_polarity(), ->disable(), ->enable(), function that were
used by PWM core.
Now, having atomic PWM, the driver should provide one function to PWM core,
which is ->apply() function. Every PWM has a state associated, which keeps
the period, duty cycle, polarity and enable/disable status. The driver's
->apply() function takes as argument the state that should be applied and
it takes care of applying this new state directly without asking user to
call ->disable(), then ->config()/->set_polarity(), then ->enable() to
apply new hardware settings.
The PWM consumer could set a new state for PWM it uses, using
pwm_apply_state(pwm, new_state);
Regarding the models to switch on atomic PWM, on the controller side you
can check for drivers that registers apply function at probe time.
Regarding the PWM users, you can look for pwm_apply_state()
(drivers/hwmon/pwm-fan.c or drivers/input/misc/pwm-beeper.c are some examples).
Thierry, please correct me if I'm wrong.
Thank you,
Claudiu Beznea
>
> BR,
> Jani.
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 03/14] iommu: Create a base struct for io_mm
Hi Jordan,
Thank you for this, SMMUv3 and virtio-iommu need these SVA patches as well.
On 21/02/18 22:59, Jordan Crouse wrote:
[...]> diff --git a/include/linux/iommu.h b/include/linux/iommu.h
> index e2c49e583d8d..e998389cf195 100644
> --- a/include/linux/iommu.h
> +++ b/include/linux/iommu.h
> @@ -110,8 +110,17 @@ struct iommu_domain {
> struct list_head mm_list;
> };
>
> +enum iommu_io_type {
> + IO_TYPE_MM,
> +};
> +
> +struct io_base {
> + int type;
> + int pasid;
> +};
"io_base" is a bit vague. I'm bad at naming so my opinion doesn't hold
much water, but I'd rather this be something like "io_mm_base". When I
initially toyed with the idea I intended to keep io_mm as parent structure
and have "private" and "shared" sub-structures. Even if private PASIDs
don't rely on the kernel mm subsystem, this structure would still
represent an I/O mm of sorts, with a pgd and pgtable info.
Thanks,
Jean
> +
> struct io_mm {
> - int pasid;
> + struct io_base base;
> struct list_headdevices;
> struct kref kref;
> #if defined(CONFIG_MMU_NOTIFIER)
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 05/10] pwm: add PWM mode to pwm_config()
On 28.02.2018 21:44, Thierry Reding wrote: > On Thu, Feb 22, 2018 at 02:01:16PM +0200, Claudiu Beznea wrote: >> Add PWM mode to pwm_config() function. The drivers which uses pwm_config() >> were adapted to this change. >> >> Signed-off-by: Claudiu Beznea >> --- >> arch/arm/mach-s3c24xx/mach-rx1950.c | 11 +-- >> drivers/bus/ts-nbus.c| 2 +- >> drivers/clk/clk-pwm.c| 3 ++- >> drivers/gpu/drm/i915/intel_panel.c | 17 ++--- >> drivers/hwmon/pwm-fan.c | 2 +- >> drivers/input/misc/max77693-haptic.c | 2 +- >> drivers/input/misc/max8997_haptic.c | 6 +- >> drivers/leds/leds-pwm.c | 5 - >> drivers/media/rc/ir-rx51.c | 5 - >> drivers/media/rc/pwm-ir-tx.c | 5 - >> drivers/video/backlight/lm3630a_bl.c | 4 +++- >> drivers/video/backlight/lp855x_bl.c | 4 +++- >> drivers/video/backlight/lp8788_bl.c | 5 - >> drivers/video/backlight/pwm_bl.c | 11 +-- >> drivers/video/fbdev/ssd1307fb.c | 3 ++- >> include/linux/pwm.h | 6 -- >> 16 files changed, 70 insertions(+), 21 deletions(-) > > I don't think it makes sense to leak mode support into the legacy API. > The pwm_config() function is considered legacy I missed this aspect. and should eventually go > away. As such it doesn't make sense to integrate a new feature such as > PWM modes into it. Agree. All users of pwm_config() assume normal mode, and > that's what pwm_config() should provide. Agree. > > Anyone that needs something other than normal mode should use the new > atomic PWM API. Agree. > > Thierry > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 1/6] dt-bindings: add bindings for USB physical connector
Hi,
On Tue, Feb 27, 2018 at 08:11:29AM +0100, Andrzej Hajda wrote:
> +2. USB-C connector attached to CC controller (s2mm005), HS lines routed
> +to companion PMIC (max77865), SS lines to USB3 PHY and SBU to DisplayPort.
> +DisplayPort video lines are routed to the connector via SS mux in USB3 PHY.
> +
> +ccic: s2mm005@33 {
> + ...
> + usb_con: connector {
> + compatible = "usb-c-connector";
> + label = "USB-C";
Is this child node really necessary? There will never be more then
one connector per CC line.
We should prefer device_graph* functions over of_graph* and
acpi_graph* functions in the drivers so we don't have to handle the
same thing multiple times with separate APIs. Is it still possible if
there is that connector child node?
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + usb_con_hs: endpoint {
> + remote-endpoint = <&max77865_usbc_hs>;
> + };
> + };
> + port@1 {
> + reg = <1>;
> + usb_con_ss: endpoint {
> + remote-endpoint = <&usbdrd_phy_ss>;
> + };
> + };
> + port@2 {
> + reg = <2>;
> + usb_con_sbu: endpoint {
> + remote-endpoint = <&dp_aux>;
> + };
> + };
> + };
> + };
> +};
Thanks,
--
heikki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
