Re: [PATCH v5 03/12] dt-bindings: display: sun4i-drm: Add LVDS properties
Hi Maxime, Dne četrtek, 21. december 2017 ob 12:02:29 CET je Maxime Ripard napisal(a): > Some clocks and resets supposed to drive the LVDS logic in the display > engine have been overlooked when the driver was first introduced. > > Add those additional resources to the binding, and we'll deal with the ABI > stability in the code. > > Reviewed-by: Chen-Yu Tsai > Reviewed-by: Rob Herring > Signed-off-by: Maxime Ripard > --- > Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 9 +++- > 1 file changed, 9 insertions(+) > > diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt > b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt index > 50cc72ee1168..1e21cfaac9e2 100644 > --- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt > +++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt > @@ -121,6 +121,15 @@ Required properties: > On SoCs other than the A33 and V3s, there is one more clock required: > - 'tcon-ch1': The clock driving the TCON channel 1 > > +On SoCs that support LVDS (all SoCs but the A13, H3, H5 and V3s), you > +need one more reset line: > + - 'lvds': The reset line driving the LVDS logic > + > +And on the SoCs newer than the A31 (sun6i and sun8i families), you > +need one more clock line: > + - 'lvds-alt': An alternative clock source, separate from the TCON > channel 0 + clock, that can be used to drive the LVDS clock I think this wording is imprecise, since A83T is part of the sun8i family, but from the code (patch 7) and DT changes (patch 9) you do, it doesn't need this property. Maybe it would be just easier to enumerate all compatibles which needs this property? Best regards, Jernej ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 09/11] drm/sun4i: Implement A83T HDMI driver
A83T has DW HDMI IP block with a custom PHY similar to Synopsys gen2
HDMI PHY.
Only video output was tested, while HW also supports audio and CEC.
Support for them will be added later.
Signed-off-by: Jernej Skrabec
---
drivers/gpu/drm/sun4i/Kconfig | 9 +
drivers/gpu/drm/sun4i/Makefile| 1 +
drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c | 367 ++
3 files changed, 377 insertions(+)
create mode 100644 drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
diff --git a/drivers/gpu/drm/sun4i/Kconfig b/drivers/gpu/drm/sun4i/Kconfig
index 882d85db9053..7327da3bc94f 100644
--- a/drivers/gpu/drm/sun4i/Kconfig
+++ b/drivers/gpu/drm/sun4i/Kconfig
@@ -40,6 +40,15 @@ config DRM_SUN4I_BACKEND
do some alpha blending and feed graphics to TCON. If M is
selected the module will be called sun4i-backend.
+config DRM_SUN8I_DW_HDMI
+ tristate "Support for Allwinner version of DesignWare HDMI"
+ depends on DRM_SUN4I
+ select DRM_DW_HDMI
+ help
+ Choose this option if you have an Allwinner SoC with the
+ DesignWare HDMI controller with custom HDMI PHY. If M is
+ selected the module will be called sun8i_dw_hdmi.
+
config DRM_SUN8I_MIXER
tristate "Support for Allwinner Display Engine 2.0 Mixer"
default MACH_SUN8I
diff --git a/drivers/gpu/drm/sun4i/Makefile b/drivers/gpu/drm/sun4i/Makefile
index 2b37a6abbb1d..d633d2b816fd 100644
--- a/drivers/gpu/drm/sun4i/Makefile
+++ b/drivers/gpu/drm/sun4i/Makefile
@@ -26,4 +26,5 @@ obj-$(CONFIG_DRM_SUN4I) += sun6i_drc.o
obj-$(CONFIG_DRM_SUN4I_BACKEND)+= sun4i-backend.o
obj-$(CONFIG_DRM_SUN4I_HDMI) += sun4i-drm-hdmi.o
+obj-$(CONFIG_DRM_SUN8I_DW_HDMI)+= sun8i_dw_hdmi.o
obj-$(CONFIG_DRM_SUN8I_MIXER) += sun8i-mixer.o
diff --git a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
new file mode 100644
index ..462bb81f11ed
--- /dev/null
+++ b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
@@ -0,0 +1,367 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2017 Jernej Skrabec
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+
+#define SUN8I_HDMI_PHY_REG_UNK10x
+#define SUN8I_HDMI_PHY_REG_POL 0x0001
+#define SUN8I_HDMI_PHY_REG_UNK20x0002
+#define SUN8I_HDMI_PHY_REG_UNK30x0003
+#define SUN8I_HDMI_PHY_REG_UNK40x0007
+
+#define SUN8I_HDMI_PHY_REG_READ_EN 0x0010
+#define SUN8I_HDMI_PHY_REG_READ_EN_MAGIC 0x54524545
+
+#define SUN8I_HDMI_PHY_REG_UNSCRAMBLE 0x0014
+#define SUN8I_HDMI_PHY_REG_UNSCRAMBLE_MAGIC0x42494E47
+
+#define to_sun8i_dw_hdmi(x)container_of(x, struct sun8i_dw_hdmi, x)
+
+struct sun8i_dw_hdmi {
+ struct clk *clk_ahb;
+ struct clk *clk_sfr;
+ struct clk *clk_tmds;
+ struct device *dev;
+ struct drm_encoder encoder;
+ void __iomem *phy_base;
+ struct dw_hdmi_plat_data plat_data;
+ struct reset_control *rst_ctrl;
+ struct reset_control *rst_phy;
+};
+
+static void sun8i_dw_hdmi_encoder_mode_set(struct drm_encoder *encoder,
+ struct drm_display_mode *mode,
+ struct drm_display_mode *adj_mode)
+{
+ struct sun8i_dw_hdmi *hdmi = to_sun8i_dw_hdmi(encoder);
+
+ clk_set_rate(hdmi->clk_tmds, mode->crtc_clock * 1000);
+}
+
+static const struct drm_encoder_helper_funcs
+sun8i_dw_hdmi_encoder_helper_funcs = {
+ .mode_set = sun8i_dw_hdmi_encoder_mode_set,
+};
+
+static void sun8i_dw_hdmi_init(struct sun8i_dw_hdmi *hdmi)
+{
+ /* enable read access to HDMI controller */
+ writel(SUN8I_HDMI_PHY_REG_READ_EN_MAGIC,
+ hdmi->phy_base + SUN8I_HDMI_PHY_REG_READ_EN);
+
+ /*
+* HDMI PHY settings are taken as-is from Allwinner BSP code.
+* There is no documentation.
+*/
+ writeb(0x01, hdmi->phy_base + SUN8I_HDMI_PHY_REG_UNK1);
+ writeb(0x00, hdmi->phy_base + SUN8I_HDMI_PHY_REG_POL);
+ writeb(0x69, hdmi->phy_base + SUN8I_HDMI_PHY_REG_UNK2);
+ writeb(0x00, hdmi->phy_base + SUN8I_HDMI_PHY_REG_UNK3);
+
+ /* unscramble register offsets */
+ writel(SUN8I_HDMI_PHY_REG_UNSCRAMBLE_MAGIC,
+ hdmi->phy_base + SUN8I_HDMI_PHY_REG_UNSCRAMBLE);
+}
+
+static const struct drm_encoder_funcs sun8i_dw_hdmi_encoder_funcs = {
+ .destroy = drm_encoder_cleanup,
+};
+
+static int sun8i_dw_hdmi_phy_init(struct dw_hdmi *dw_hdmi, void *data,
+ struct drm_display_mode *mode)
+{
+ struct sun8i_dw_hdmi *hdmi = (struct sun8i_dw_hdmi *)data;
+ u8 val = 0;
+
+ if ((mode->flags & DRM_MODE_FLAG_NHSYNC) &&
+ (mode->flags & DRM_MODE_FLAG_NHSYNC)) {
+ val = 0x03;
+ }
+
+ writeb(0xa0, hdmi->phy_base + SUN8I_HDMI_PHY_REG_UNK4);
+
+ writeb(v
[PATCH 06/11] dt-bindings: display: sun4i-drm: Add A83T HDMI pipeline
This commit adds all necessary compatibles and descriptions needed to implement A83T HDMI pipeline. Mixer is already properly described, so only compatible is added. However, A83T TCON1, which is connected to HDMI, doesn't have channel 0, contrary to all TCONs currently described. Because of that, TCON documentation is extended. A83T features Synopsys DW HDMI controller with a custom PHY which looks like Synopsys Gen2 PHY with few additions. Since there is no documentation, needed properties were found out through experimentation and reading BSP code. At the end, example is added for newer SoCs, which features DE2 and DW HDMI. Signed-off-by: Jernej Skrabec --- .../bindings/display/sunxi/sun4i-drm.txt | 188 - 1 file changed, 181 insertions(+), 7 deletions(-) diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt index 9f073af4c711..3eca258096a5 100644 --- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt +++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt @@ -64,6 +64,40 @@ Required properties: first port should be the input endpoint. The second should be the output, usually to an HDMI connector. +DWC HDMI TX Encoder +- + +The HDMI transmitter is a Synopsys DesignWare HDMI 1.4 TX controller IP +with Allwinner's own PHY IP. It supports audio and video outputs and CEC. + +These DT bindings follow the Synopsys DWC HDMI TX bindings defined in +Documentation/devicetree/bindings/display/bridge/dw_hdmi.txt with the +following device-specific properties. + +Required properties: + + - compatible: value must be one of: +* "allwinner,sun8i-a83t-dw-hdmi" + - reg: two pairs of base address and size of memory-mapped region, first +for controller and second for PHY +registers. + - reg-io-width: See dw_hdmi.txt. Shall be 1. + - interrupts: HDMI interrupt number + - clocks: phandles to the clocks feeding the HDMI encoder +* iahb: the HDMI bus clock +* isfr: the HDMI register clock +* tmds: the HDMI tmds clock + - clock-names: the clock names mentioned above + - resets: phandles to the reset controllers driving the encoder +* ctrl: the reset line for the controller +* phy: the reset line for the PHY + - reset-names: the reset names mentioned above + + - ports: A ports node with endpoint definitions as defined in +Documentation/devicetree/bindings/media/video-interfaces.txt. The +first port should be the input endpoint. The second should be the +output, usually to an HDMI connector. + TV Encoder -- @@ -94,18 +128,17 @@ Required properties: * allwinner,sun7i-a20-tcon * allwinner,sun8i-a33-tcon * allwinner,sun8i-a83t-tcon-lcd + * allwinner,sun8i-a83t-tcon-tv * allwinner,sun8i-v3s-tcon - reg: base address and size of memory-mapped region - interrupts: interrupt associated to this IP - - clocks: phandles to the clocks feeding the TCON. Three are needed: + - clocks: phandles to the clocks feeding the TCON. One is needed: - 'ahb': the interface clocks - - 'tcon-ch0': The clock driving the TCON channel 0 - resets: phandles to the reset controllers driving the encoder - "lcd": the reset line for the TCON channel 0 - clock-names: the clock names mentioned above - reset-names: the reset names mentioned above - - clock-output-names: Name of the pixel clock created - ports: A ports node with endpoint definitions as defined in Documentation/devicetree/bindings/media/video-interfaces.txt. The @@ -119,11 +152,31 @@ Required properties: channel the endpoint is associated to. If that property is not present, the endpoint number will be used as the channel number. -On SoCs other than the A33 and V3s, there is one more clock required: +Following compatibles: + * allwinner,sun4i-a10-tcon + * allwinner,sun5i-a13-tcon + * allwinner,sun6i-a31-tcon + * allwinner,sun6i-a31s-tcon + * allwinner,sun7i-a20-tcon + * allwinner,sun8i-a33-tcon + * allwinner,sun8i-a83t-tcon-lcd + * allwinner,sun8i-v3s-tcon +have additional required properties: + - 'tcon-ch0': The clock driving the TCON channel 0 + - clock-output-names: Name of the pixel clock created + +For following compatibles: + * allwinner,sun4i-a10-tcon + * allwinner,sun5i-a13-tcon + * allwinner,sun6i-a31-tcon + * allwinner,sun6i-a31s-tcon + * allwinner,sun7i-a20-tcon + * allwinner,sun8i-a83t-tcon-tv +there is one more clock required: - 'tcon-ch1': The clock driving the TCON channel 1 -On SoCs that support LVDS (all SoCs but the A13, H3, H5 and V3s), you -need one more reset line: +On TCONs that support LVDS (all TCONs except the ones found on A13, H3, H5, V3s +and TCON1 on A83T), you need one more reset line: - 'lvds': The reset line driving the LVDS logic And on the SoCs newer than the A31 (sun6i and sun8i families), you @@ -227,6 +280,7 @@ supported. Required properties: - comp
[PATCH] drivers: gpu: drm: Fix warning for incomplete Declarations in client.c
This patch fixes the Sparse Warning "symbol was
not declared. Should it be static?" in nvkm/core/client.c
Signed-off-by: Vaibhav Kothari
---
drivers/gpu/drm/nouveau/nvkm/core/client.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/core/client.c
b/drivers/gpu/drm/nouveau/nvkm/core/client.c
index ac67120..0c8c55c 100644
--- a/drivers/gpu/drm/nouveau/nvkm/core/client.c
+++ b/drivers/gpu/drm/nouveau/nvkm/core/client.c
@@ -60,7 +60,7 @@ nvkm_uclient_new(const struct nvkm_oclass *oclass, void
*argv, u32 argc,
return 0;
}
-const struct nvkm_sclass
+static const struct nvkm_sclass
nvkm_uclient_sclass = {
.oclass = NVIF_CLASS_CLIENT,
.minver = 0,
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 03/11] drm/bridge/synopsys: dw-hdmi: Enable workaround for v1.32a
Allwinner SoCs have dw hdmi controller v1.32a which exhibits same
magenta line issue as i.MX6Q and i.MX6DL. Enable workaround for it.
Tests show that one iteration is enough.
Signed-off-by: Jernej Skrabec
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index a38db40ce990..7ca14d7325b5 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -1634,9 +1634,10 @@ static void dw_hdmi_clear_overflow(struct dw_hdmi *hdmi)
* then write one of the FC registers several times.
*
* The number of iterations matters and depends on the HDMI TX revision
-* (and possibly on the platform). So far only i.MX6Q (v1.30a) and
-* i.MX6DL (v1.31a) have been identified as needing the workaround, with
-* 4 and 1 iterations respectively.
+* (and possibly on the platform). So far i.MX6Q (v1.30a), i.MX6DL
+* (v1.31a) and multiple Allwinner SoCs (v1.32a) have been identified
+* as needing the workaround, with 4 iterations for v1.30a and 1
+* iteration for others.
*/
switch (hdmi->version) {
@@ -1644,6 +1645,7 @@ static void dw_hdmi_clear_overflow(struct dw_hdmi *hdmi)
count = 4;
break;
case 0x131a:
+ case 0x132a:
count = 1;
break;
default:
--
2.15.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/vc4: Move IRQ enable to PM path
> Stefan Schake hat am 29. Dezember 2017 um 17:05
> geschrieben:
>
>
> We were calling enable_irq on bind, where it was already enabled previously
> by the IRQ helper. Additionally, dev->irq is not set correctly until after
> postinstall and so was always zero here, triggering a warning in 4.15.
> Fix both by moving the enable to the power management resume path, where we
> know there was a previous disable invocation during suspend.
>
> Fixes: 253696ccd613 ("drm/vc4: Account for interrupts in flight")
> Signed-off-by: Stefan Schake
Tested-by: Stefan Wahren
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/ttm: optimize errors checking and free _manager when finishing
In the function ttm_page_alloc_init, kzalloc call is made for variable
_manager, we need to check its return value, it may return NULL.
In the function ttm_page_alloc_fini, we need to call kfree for variable
_manager, instead of make _manager NULL directly.
Signed-off-by: Xiongwei Song
---
drivers/gpu/drm/ttm/ttm_page_alloc.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index b5ba6441489f..e20a0b8e352b 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -1007,6 +1007,10 @@ int ttm_page_alloc_init(struct ttm_mem_global *glob,
unsigned max_pages)
pr_info("Initializing pool allocator\n");
_manager = kzalloc(sizeof(*_manager), GFP_KERNEL);
+ if (!_manager) {
+ ret = -ENOMEM;
+ goto out;
+ }
ttm_page_pool_init_locked(&_manager->wc_pool, GFP_HIGHUSER, "wc", 0);
@@ -1034,13 +1038,17 @@ int ttm_page_alloc_init(struct ttm_mem_global *glob,
unsigned max_pages)
&glob->kobj, "pool");
if (unlikely(ret != 0)) {
kobject_put(&_manager->kobj);
- _manager = NULL;
- return ret;
+ goto out_free_mgr;
}
ttm_pool_mm_shrink_init(_manager);
return 0;
+out_free_mgr:
+ kfree(_manager);
+ _manager = NULL;
+out:
+ return ret;
}
void ttm_page_alloc_fini(void)
@@ -1055,6 +1063,7 @@ void ttm_page_alloc_fini(void)
ttm_page_pool_free(&_manager->pools[i], FREE_ALL_PAGES, true);
kobject_put(&_manager->kobj);
+ kfree(_manager);
_manager = NULL;
}
--
2.15.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V4 23/26] video: fbdev: nvidia: deprecate pci_get_bus_and_slot()
On 12/19/2017 12:37 AM, Sinan Kaya wrote: > pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as > where a PCI device is present. This restricts the device drivers to be > reused for other domain numbers. > > Getting ready to remove pci_get_bus_and_slot() function in favor of > pci_get_domain_bus_and_slot(). > > struct nvidia_par has a pointer to struct pci_dev. Use the pci_dev > member to extract the domain information and pass it to > pci_get_domain_bus_and_slot() function. > > Signed-off-by: Sinan Kaya Any feedback here ? most of the remaining patches have the ACK except these. -- Sinan Kaya Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 05/11] drm/bridge/synopsys: dw-hdmi: Add deinit callback
Some SoCs, like Allwinner A83T, have to do additional cleanup when
HDMI driver unloads. When using DW HDMI through DRM bridge API, there is
no place to store driver's private data so it can be accessed in unbind
function. Because of that, add deinit function which is called at the
very end, so drivers can do a proper cleanup.
Signed-off-by: Jernej Skrabec
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 3 +++
include/drm/bridge/dw_hdmi.h | 1 +
2 files changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index 67467d0b683a..a6fe7a323c83 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -2592,6 +2592,9 @@ static void __dw_hdmi_remove(struct dw_hdmi *hdmi)
i2c_del_adapter(&hdmi->i2c->adap);
else
i2c_put_adapter(hdmi->ddc);
+
+ if (hdmi->plat_data->deinit)
+ hdmi->plat_data->deinit(hdmi->plat_data);
}
/*
-
diff --git a/include/drm/bridge/dw_hdmi.h b/include/drm/bridge/dw_hdmi.h
index f5cca4362154..a3218d3da61b 100644
--- a/include/drm/bridge/dw_hdmi.h
+++ b/include/drm/bridge/dw_hdmi.h
@@ -124,6 +124,7 @@ struct dw_hdmi_phy_ops {
struct dw_hdmi_plat_data {
struct regmap *regm;
+ void (*deinit)(const struct dw_hdmi_plat_data *pdata);
enum drm_mode_status (*mode_valid)(struct drm_connector *connector,
const struct drm_display_mode *mode);
unsigned long input_bus_format;
--
2.15.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 11/11] ARM: dts: sun8i: a83t: Enable HDMI on BananaPi M3
BananaPi M3 includes HDMI connector, so add support for it.
Signed-off-by: Jernej Skrabec
---
arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts | 29
1 file changed, 29 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
b/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
index 6550bf0e594b..2002d249e14c 100644
--- a/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
+++ b/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
@@ -60,6 +60,17 @@
stdout-path = "serial0:115200n8";
};
+ connector {
+ compatible = "hdmi-connector";
+ type = "a";
+
+ port {
+ hdmi_con_in: endpoint {
+ remote-endpoint = <&hdmi_out_con>;
+ };
+ };
+ };
+
reg_usb1_vbus: reg-usb1-vbus {
compatible = "regulator-fixed";
regulator-name = "usb1-vbus";
@@ -82,6 +93,10 @@
};
};
+&de {
+ status = "okay";
+};
+
&ehci0 {
/* Terminus Tech FE 1.1s 4-port USB 2.0 hub here */
status = "okay";
@@ -100,6 +115,16 @@
status = "okay";
};
+&hdmi {
+ status = "okay";
+};
+
+&hdmi_out {
+ hdmi_out_con: endpoint {
+ remote-endpoint = <&hdmi_con_in>;
+ };
+};
+
&mdio {
rgmii_phy: ethernet-phy@1 {
compatible = "ethernet-phy-ieee802.3-c22";
@@ -306,6 +331,10 @@
regulator-name = "vcc-ephy";
};
+&tcon1 {
+ status = "okay";
+};
+
&uart0 {
pinctrl-names = "default";
pinctrl-0 = <&uart0_pb_pins>;
--
2.15.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V4 22/26] video: fbdev: intelfb: deprecate pci_get_bus_and_slot()
On 12/19/2017 12:37 AM, Sinan Kaya wrote: > pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as > where a PCI device is present. This restricts the device drivers to be > reused for other domain numbers. > > Getting ready to remove pci_get_bus_and_slot() function in favor of > pci_get_domain_bus_and_slot(). > > Find the domain number from pdev. > > Signed-off-by: Sinan Kaya Any feedback here ? most of the remaining patches have the ACK except these. -- Sinan Kaya Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 25/25] drm/armada: add iturbt_709 plane property to control YUV colorspace
On Wed, Dec 13, 2017 at 06:22:14PM +0200, Ville Syrjälä wrote:
> On Wed, Dec 13, 2017 at 11:12:18AM -0500, Ilia Mirkin wrote:
> > On Wed, Dec 13, 2017 at 10:41 AM, Daniel Stone wrote:
> > > Hi Russell,
> > >
> > > On 8 December 2017 at 12:31, Russell King
> > > wrote:
> > >> Add the defacto-standard "iturbt_709" property to the overlay plane to
> > >> control the YUV to RGB colorspace conversion. This is mutually
> > >> exclusive with the CSC_YUV CRTC property - the last property to be set
> > >> determines the resulting colorspace conversion.
> > >
> > > I haven't seen this in other drivers - is it a 'defacto standard'? I
> >
> > xf86-video-nv supported it, and I added it to nouveau as well when I
> > ported YUV plane support. Some video players use the Xv property when
> > available.
> >
> > https://cgit.freedesktop.org/xorg/driver/xf86-video-nv/tree/src/nv_video.c#n128
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/nouveau/dispnv04/overlay.c?h=v4.15-rc3#n316
>
>{XvSettable | XvGettable, 0, 1, "XV_ITURBT_709"}
>
> Who came up with that and when? XV_COLORSPACE was the one semi-standard
> I know of.
I've no idea, and I was hoping that someone else would know - my use of
it comes from research into what will make userspace work, not what
standards may say.
XV_ITURBT_709 is already in-use in distro standard userspace programs:
# grep XV_ITURBT_709 /usr/lib/vlc/plugins/ -r
Binary file /usr/lib/vlc/plugins/video_output/libxcb_xv_plugin.so matches
# grep XV_ITURBT_709 /usr/lib/gstreamer-1.0/ -r
Binary file /usr/lib/gstreamer-1.0/libgstxvimagesink.so matches
but not XV_COLORSPACE:
# grep XV_COLORSPACE /usr/lib/vlc/plugins/ -r
# grep XV_COLORSPACE /usr/lib/gstreamer-1.0/ -r
So while XV_COLORSPACE may be some kind of standard, it seems that
userspace has decided otherwise to go with a different name for this
control.
Anyway, I'll drop this patch and send a pull request for the remainder
to David.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: nouveau. swiotlb: coherent allocation failed for device 0000:01:00.0 size=2097152
On Sun, 2017-12-31 at 13:27 -0500, Ilia Mirkin wrote: > On Tue, Dec 19, 2017 at 8:45 AM, Christian König > wrote: > > Am 19.12.2017 um 11:39 schrieb Michel Dänzer: > >> > >> On 2017-12-19 11:37 AM, Michel Dänzer wrote: > >>> > >>> On 2017-12-18 08:01 PM, Tobias Klausmann wrote: > > On 12/18/17 7:06 PM, Mike Galbraith wrote: > > > > Greetings, > > > > Kernel bound workloads seem to trigger the below for whatever reason. > >I only see this when beating up NFS. There was a kworker wakeup > > latency issue, but with a bandaid applied to fix that up, I can still > > trigger this. > > > Hi, > > i have seen this one as well with my system, but i could not find an > easy way to trigger it for bisecting purpose. If you can trigger it > conveniently, a bisect would be nice! > >>> > >>> I'm seeing this (with the amdgpu and radeon drivers) when restic takes a > >>> backup, creating memory pressure. I happen to have just finished > >>> bisecting, the result is: > >>> > >>> 648bc3574716400acc06f99915815f80d9563783 is the first bad commit > >>> commit 648bc3574716400acc06f99915815f80d9563783 > >>> Author: Christian König > >>> Date: Thu Jul 6 09:59:43 2017 +0200 > >>> > >>> drm/ttm: add transparent huge page support for DMA allocations v2 > >>> > >>> Try to allocate huge pages when it makes sense. > >>> > >>> v2: fix comment and use ifdef > >>> > >>> > >> BTW, I haven't noticed any bad effects other than the dmesg splats, so > >> maybe it's just noise about transient failures for which there is a > >> proper fallback in place. > > > > > > Yeah, I think that is exactly what happens here. > > > > We try to allocate a huge page, but fail and so fall back to using multiple > > 4k pages instead. > > > > Going to send out a patch to suppress the warning. > > Hi Christian, > > Did you ever send out such a patch? I didn't see one on the list, but > perhaps I missed it. One definitely hasn't made it upstream yet. (I > just hit the issue myself with Linus's tree from last night.) Actually, that wants a bit more methinks, because while the stack dump goes away, you still get spammed, it just comes in smaller chunks. -Mike ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 01/11] clk: sunxi-ng: Don't set k if width is 0 for nkmp plls
For example, A83T have nmp plls which are modelled as nkmp plls. Since k
is not specified, it has offset 0, shift 0 and lowest value 1. This
means that LSB bit is always set to 1, which may change clock rate.
Fix that by applying k factor only if k width is greater than 0.
Signed-off-by: Jernej Skrabec
---
drivers/clk/sunxi-ng/ccu_nkmp.c | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/drivers/clk/sunxi-ng/ccu_nkmp.c b/drivers/clk/sunxi-ng/ccu_nkmp.c
index e58c95787f94..709f528af2b3 100644
--- a/drivers/clk/sunxi-ng/ccu_nkmp.c
+++ b/drivers/clk/sunxi-ng/ccu_nkmp.c
@@ -81,7 +81,7 @@ static unsigned long ccu_nkmp_recalc_rate(struct clk_hw *hw,
unsigned long parent_rate)
{
struct ccu_nkmp *nkmp = hw_to_ccu_nkmp(hw);
- unsigned long n, m, k, p;
+ unsigned long n, m, k = 1, p;
u32 reg;
reg = readl(nkmp->common.base + nkmp->common.reg);
@@ -92,11 +92,13 @@ static unsigned long ccu_nkmp_recalc_rate(struct clk_hw *hw,
if (!n)
n++;
- k = reg >> nkmp->k.shift;
- k &= (1 << nkmp->k.width) - 1;
- k += nkmp->k.offset;
- if (!k)
- k++;
+ if (nkmp->k.width) {
+ k = reg >> nkmp->k.shift;
+ k &= (1 << nkmp->k.width) - 1;
+ k += nkmp->k.offset;
+ if (!k)
+ k++;
+ }
m = reg >> nkmp->m.shift;
m &= (1 << nkmp->m.width) - 1;
@@ -153,12 +155,15 @@ static int ccu_nkmp_set_rate(struct clk_hw *hw, unsigned
long rate,
reg = readl(nkmp->common.base + nkmp->common.reg);
reg &= ~GENMASK(nkmp->n.width + nkmp->n.shift - 1, nkmp->n.shift);
- reg &= ~GENMASK(nkmp->k.width + nkmp->k.shift - 1, nkmp->k.shift);
+ if (nkmp->k.width)
+ reg &= ~GENMASK(nkmp->k.width + nkmp->k.shift - 1,
+ nkmp->k.shift);
reg &= ~GENMASK(nkmp->m.width + nkmp->m.shift - 1, nkmp->m.shift);
reg &= ~GENMASK(nkmp->p.width + nkmp->p.shift - 1, nkmp->p.shift);
reg |= (_nkmp.n - nkmp->n.offset) << nkmp->n.shift;
- reg |= (_nkmp.k - nkmp->k.offset) << nkmp->k.shift;
+ if (nkmp->k.width)
+ reg |= (_nkmp.k - nkmp->k.offset) << nkmp->k.shift;
reg |= (_nkmp.m - nkmp->m.offset) << nkmp->m.shift;
reg |= ilog2(_nkmp.p) << nkmp->p.shift;
--
2.15.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC HACK 2/2] clk: meson: meson8b: add the video clock trees - WiP
vdac0 shows 27MHz on Meson8m2
1080P HDMI mode shows weird results (not verified yet)
differences to the video clocks in the GX SoCs:
- HHI_VID_DIVIDER_CNTL is unique to Meson8/Meson8b/Meson8m2. the GX SoCs
use some other logic and the HHI_VID_PLL_CLK_DIV register instead
- the final ENCT/ENCP/ENCI/ENCL/VDAC0/HDMI_TX_PIXEL clocks can not use
both, vclk and vclk2 as input (ENCT, ENCP and ENCI are defined in
HHI_VID_CLK_DIV so they use the vclk dividers, while ENCL, VDAC0 and
HDMI_TX_PIXEL are defined in HHI_VIID_CLK_DIV and HHI_HDMI_CLK_CNTL so
they use the vclk2 dividers)
WiP
Signed-off-by: Martin Blumenstingl
---
drivers/clk/meson/meson8b.c | 637 +++
drivers/clk/meson/meson8b.h | 7 +-
include/dt-bindings/clock/meson8b-clkc.h | 42 ++
3 files changed, 685 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/meson/meson8b.c b/drivers/clk/meson/meson8b.c
index 365092a30b37..6642412808c8 100644
--- a/drivers/clk/meson/meson8b.c
+++ b/drivers/clk/meson/meson8b.c
@@ -515,6 +515,567 @@ struct clk_gate meson8b_nand_clk_gate = {
},
};
+struct clk_divider meson8b_vid_pll_pre_div = {
+ .reg = (void *)HHI_VID_DIVIDER_CNTL,
+ .shift = 4,
+ .width = 3,
+ .lock = &clk_lock,
+ .hw.init = &(struct clk_init_data){
+ .name = "vid_pll_pre_div",
+ .ops = &clk_divider_ops,
+ .parent_names = (const char *[]){ "vid_pll" },
+ .num_parents = 1,
+ .flags = CLK_SET_RATE_PARENT,
+ },
+};
+
+struct clk_divider meson8b_vid_pll_post_div = {
+ .reg = (void *)HHI_VID_DIVIDER_CNTL,
+ .shift = 12,
+ .width = 3,
+ .lock = &clk_lock,
+ .hw.init = &(struct clk_init_data){
+ .name = "vid_pll_post_div",
+ .ops = &clk_divider_ops,
+ .parent_names = (const char *[]){ "vid_pll_pre_div" },
+ .num_parents = 1,
+ .flags = CLK_SET_RATE_PARENT,
+ },
+};
+
+struct clk_mux meson8b_vid_pll_post_sel = {
+ .reg = (void *)HHI_VID_DIVIDER_CNTL,
+ .mask = 0x3,
+ .shift = 8,
+ .lock = &clk_lock,
+ .hw.init = &(struct clk_init_data){
+ .name = "vid_pll_post_sel",
+ .ops = &clk_mux_ops,
+ .parent_names = (const char *[]){ "vid_pll_pre_div",
+ "vid_pll_post_div" },
+ .num_parents = 2,
+ .flags = CLK_SET_RATE_PARENT,
+ },
+};
+
+struct clk_gate meson8b_vid_pll_post_en = {
+ .reg = (void *)HHI_VID_DIVIDER_CNTL,
+ .bit_idx = 16,
+ .lock = &clk_lock,
+ .hw.init = &(struct clk_init_data){
+ .name = "vid_pll_post_en",
+ .ops = &clk_mux_ops,
+ .parent_names = (const char *[]){ "vid_pll_post_sel", },
+ .num_parents = 1,
+ .flags = (CLK_SET_RATE_PARENT | CLK_IGNORE_UNUSED),
+ },
+};
+
+static const char * const meson8b_vclk_mux_parents[] = {
+ "vid_pll_post_en", "fclk_div4", "fclk_div3", "fclk_div5",
+ "vid_pll_post_en", "fclk_div7", "mpll1"
+};
+
+struct clk_mux meson8b_vclk_sel = {
+ .reg = (void *)HHI_VID_CLK_CNTL,
+ .mask = 0x7,
+ .shift = 16,
+ .lock = &clk_lock,
+ .hw.init = &(struct clk_init_data){
+ .name = "vclk_sel",
+ .ops = &clk_mux_ops,
+ .parent_names = meson8b_vclk_mux_parents,
+ .num_parents = ARRAY_SIZE(meson8b_vclk_mux_parents),
+ .flags = CLK_SET_RATE_PARENT,
+ },
+};
+
+struct clk_gate meson8b_vclk_en0_gate = {
+ .reg = (void *)HHI_VID_CLK_CNTL,
+ .bit_idx = 19,
+ .lock = &clk_lock,
+ .hw.init = &(struct clk_init_data){
+ .name = "vclk_en0",
+ .ops = &clk_mux_ops,
+ .parent_names = (const char *[]){ "vclk_sel" },
+ .num_parents = 1,
+ .flags = (CLK_SET_RATE_PARENT | CLK_IGNORE_UNUSED),
+ },
+};
+
+struct clk_divider meson8b_vclk_xd0_div = {
+ .reg = (void *)HHI_VID_CLK_DIV,
+ .shift = 0,
+ .width = 8,
+ .lock = &clk_lock,
+ .hw.init = &(struct clk_init_data){
+ .name = "vclk_xd0",
+ .ops = &clk_divider_ops,
+ .parent_names = (const char *[]){ "vclk_en0" },
+ .num_parents = 1,
+ .flags = CLK_SET_RATE_PARENT,
+ },
+};
+
+struct clk_gate meson8b_vclk_clk_div_gate = {
+ .reg = (void *)HHI_VID_CLK_DIV,
+ .bit_idx = 16,
+ .lock = &clk_lock,
+ .hw.init = &(struct clk_init_data){
+ .name = "vclk_clk_div_en",
+ .ops = &clk_gate_ops,
+ .parent_names = (const char *[]){ "vclk_xd0" },
+ .num_parents = 1,
+ .flags = (CLK_SET_RATE_PARENT | CLK_IGNORE_UNUSED),
+ },
+};
+
+struct clk_gate meson8b_vclk_div1_gate = {
+ .reg = (void *)
[PATCH 08/11] drm/sun4i: Add support for A83T second DE2 mixer
It supports 1 VI and 1 UI plane and HW scaling on both planes.
Signed-off-by: Jernej Skrabec
---
drivers/gpu/drm/sun4i/sun8i_mixer.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.c
b/drivers/gpu/drm/sun4i/sun8i_mixer.c
index 2cbb2de6d39c..9b0256d31a61 100644
--- a/drivers/gpu/drm/sun4i/sun8i_mixer.c
+++ b/drivers/gpu/drm/sun4i/sun8i_mixer.c
@@ -485,6 +485,13 @@ static const struct sun8i_mixer_cfg sun8i_a83t_mixer0_cfg
= {
.vi_num = 1,
};
+static const struct sun8i_mixer_cfg sun8i_a83t_mixer1_cfg = {
+ .ccsc = 1,
+ .scaler_mask= 0x3,
+ .ui_num = 1,
+ .vi_num = 1,
+};
+
static const struct sun8i_mixer_cfg sun8i_v3s_mixer_cfg = {
.vi_num = 2,
.ui_num = 1,
@@ -498,6 +505,10 @@ static const struct of_device_id sun8i_mixer_of_table[] = {
.compatible = "allwinner,sun8i-a83t-de2-mixer-0",
.data = &sun8i_a83t_mixer0_cfg,
},
+ {
+ .compatible = "allwinner,sun8i-a83t-de2-mixer-1",
+ .data = &sun8i_a83t_mixer1_cfg,
+ },
{
.compatible = "allwinner,sun8i-v3s-de2-mixer",
.data = &sun8i_v3s_mixer_cfg,
--
2.15.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC HACK 0/2] CVBS output on Meson8/Meson8b/Meson8m2
Hi Neil, DISCLAIMER: none of these patches is meant to be applied anywhere! their purpose is to document what I found out so far (things that are not documented in any public datasheet that I am aware of). I was curious and wanted to see if there are any differences between the video IP blocks between Meson8/Meson8b/Meson8m2 and GXBB/GXL/GXM. after reading your gpu/drm/meson/meson_vclk.c I stumbled across the first problem (which is a big one): the 32-bit SoCs don't have the HHI_VID_PLL_CLK_DIV register. unfortunately there is no documentation in the public S805 datasheet that describes the video clock path on Meson8b. some of the registers that are documented in the GXM datasheet published by Khadas (which also contains a nice video clock tree documentation). so I tried to take a different approach: extending the clock controller driver so I could play around until I could read the clock frequencies set by u-boot (which displays an image on the CVBS output). the result of this is the clock patch from this series, which gives me the following output in /sys/kernel/debug/clk/clk_summary: vid_pll 00 64800 0 0 vid_pll_pre_div00 10800 0 0 vid_pll_post_sel00 10800 0 0 vid_pll_post_en 00 10800 0 0 vclk2_sel 00 10800 0 0 vclk2_en0 00 10800 0 0 vclk2_xd0 005400 0 0 vclk2_clk_div_en 005400 0 0 vclk2_div12 00 450 0 0 vclk2_div12_en 00 450 0 0 vclk2_div6 00 900 0 0 vclk2_div6_en 00 900 0 0 vclk2_div4 001350 0 0 vclk2_div4_en 001350 0 0 vclk2_div2 002700 0 0 vclk2_div2_en 002700 0 0 hdmi_tx_pixel_sel 00 2700 0 0 hdmi_tx_pixel_en 00 2700 0 0 vdac0_sel 002700 0 0 vdac0_en 002700 0 0 vclk2_div1_en 005400 0 0 encl_sel 005400 0 0 encl_en 005400 0 0 vclk_sel 00 10800 0 0 vclk_en0 00 10800 0 0 vclk_xd0002700 0 0 vclk_clk_div_en 002700 0 0 vclk_div12 00 225 0 0 vclk_div12_en 00 225 0 0 vclk_div6 00 450 0 0 vclk_div6_en 00 450 0 0 vclk_div4 00 675 0 0 vclk_div4_en 00 675 0 0 vclk_div2 001350 0 0 vclk_div2_en 001350 0 0 enci_sel 001350 0 0 enci_en 001350 0 0 vclk_div1_en 002700 0 0 encp_sel 002700 0 0 encp_en 002700 0 0 enct_sel 002700 0 0 enct_en 002700 0 0 vid_pll_post_div00 10800 0 0 I am not sure whether the ENCI clock is supposed to be 27MHz. at least the VDAC
[PATCH 00/11] drm/sun4i: Add A83T HDMI support
This patch series implements support for A83T DW HDMI and PHY. It is based upon Maxime Ripard's "drm/sun4i: Add A83t LVDS support" patch series which can be found here: http://lists.infradead.org/pipermail/linux-arm-kernel/2017-December/550035.html While exactly this combination of HDMI controller and PHY is not common in Allwinner SoCs, this patch series nevertheless makes groundwork for other SoCs, which have same DW HDMI IP block, but different PHYs, like H3 and H5. All patches can also be found on github: https://github.com/jernejsk/linux-1/commits/a83t_hdmi Please take a look. Best regards, Jernej Jernej Skrabec (11): clk: sunxi-ng: Don't set k if width is 0 for nkmp plls clk: sunxi-ng: a83t: Add M divider to TCON1 clock drm/bridge/synopsys: dw-hdmi: Enable workaround for v1.32a drm/bridge/synopsys: dw-hdmi: Export some PHY related functions drm/bridge/synopsys: dw-hdmi: Add deinit callback dt-bindings: display: sun4i-drm: Add A83T HDMI pipeline drm/sun4i: Add support for A83T second TCON drm/sun4i: Add support for A83T second DE2 mixer drm/sun4i: Implement A83T HDMI driver ARM: dts: sun8i: a83t: Add HDMI display pipeline ARM: dts: sun8i: a83t: Enable HDMI on BananaPi M3 .../bindings/display/sunxi/sun4i-drm.txt | 188 ++- arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts | 29 ++ arch/arm/boot/dts/sun8i-a83t.dtsi | 108 +- drivers/clk/sunxi-ng/ccu-sun8i-a83t.c | 4 +- drivers/clk/sunxi-ng/ccu_nkmp.c| 21 +- drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 56 +++- drivers/gpu/drm/bridge/synopsys/dw-hdmi.h | 2 + drivers/gpu/drm/sun4i/Kconfig | 9 + drivers/gpu/drm/sun4i/Makefile | 1 + drivers/gpu/drm/sun4i/sun4i_tcon.c | 46 ++- drivers/gpu/drm/sun4i/sun4i_tcon.h | 1 + drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c | 367 + drivers/gpu/drm/sun4i/sun8i_mixer.c| 11 + include/drm/bridge/dw_hdmi.h | 11 + 14 files changed, 808 insertions(+), 46 deletions(-) create mode 100644 drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c -- 2.15.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC HACK 1/2] gpu: drm: meson: HACK - Meson8/Meson8b/Meson8m2 support - WiP
TODO:
- canvas registers offsets on Meson8 / Meson8b are different
- hardcoded register values
- OSD2 is used for CVBS on Meson8 (at least on Meson8m2)
Signed-off-by: Martin Blumenstingl
---
.../bindings/display/amlogic,meson-vpu.txt | 18 +-
drivers/gpu/drm/meson/meson_canvas.c | 11 +
drivers/gpu/drm/meson/meson_canvas.h | 4 ++--
drivers/gpu/drm/meson/meson_drv.c | 3 +++
drivers/gpu/drm/meson/meson_plane.c| 5 ++--
drivers/gpu/drm/meson/meson_vclk.c | 21 ++--
drivers/gpu/drm/meson/meson_venc_cvbs.c| 5 +++-
drivers/gpu/drm/meson/meson_viu.c | 5 +++-
drivers/gpu/drm/meson/meson_vpp.c | 28 ++
9 files changed, 86 insertions(+), 14 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/amlogic,meson-vpu.txt
b/Documentation/devicetree/bindings/display/amlogic,meson-vpu.txt
index 00f74bad1e95..f416cdc88f25 100644
--- a/Documentation/devicetree/bindings/display/amlogic,meson-vpu.txt
+++ b/Documentation/devicetree/bindings/display/amlogic,meson-vpu.txt
@@ -53,6 +53,9 @@ VPU: Video Processing Unit
Required properties:
- compatible: value should be different for each SoC family as :
+ - Meson8 (S802) : "amlogic,meson8-vpu"
+ - Meson8b (S805) : "amlogic,meson8b-vpu"
+ - Meson8m2 (S812) : "amlogic,meson8m2-vpu"
- GXBB (S905) : "amlogic,meson-gxbb-vpu"
- GXL (S905X, S905D) : "amlogic,meson-gxl-vpu"
- GXM (S912) : "amlogic,meson-gxm-vpu"
@@ -72,12 +75,15 @@ bindings specified in
Documentation/devicetree/bindings/graph.txt.
The following table lists for each supported model the port number
corresponding to each VPU output.
- Port 0 Port 1
--
- S905 (GXBB) CVBS VDAC HDMI-TX
- S905X (GXL) CVBS VDAC HDMI-TX
- S905D (GXL) CVBS VDAC HDMI-TX
- S912 (GXM)CVBS VDAC HDMI-TX
+ Port 0 Port 1
+---
+ S802 (Meson8) CVBS VDAC not implemented yet
+ S805 (Meson8b)CVBS VDAC not implemented yet
+ S812 (Meson8m2) CVBS VDAC not implemented yet
+ S905 (GXBB) CVBS VDAC HDMI-TX
+ S905X (GXL) CVBS VDAC HDMI-TX
+ S905D (GXL) CVBS VDAC HDMI-TX
+ S912 (GXM)CVBS VDAC HDMI-TX
Example:
diff --git a/drivers/gpu/drm/meson/meson_canvas.c
b/drivers/gpu/drm/meson/meson_canvas.c
index 08f6073d967e..cc741d06ccc4 100644
--- a/drivers/gpu/drm/meson/meson_canvas.c
+++ b/drivers/gpu/drm/meson/meson_canvas.c
@@ -43,6 +43,17 @@
#define CANVAS_LUT_WR_EN(0x2 << 8)
#define CANVAS_LUT_RD_EN(0x1 << 8)
+u8 meson_canvas_id_osd1(struct meson_drm *priv)
+{
+ if (meson_vpu_is_compatible(priv, "amlogic,meson8-vpu") ||
+ meson_vpu_is_compatible(priv, "amlogic,meson8b-vpu") ||
+ meson_vpu_is_compatible(priv, "amlogic,meson8m2-vpu")) {
+ return 0x43; // HACK: OSD1 = 0x40, OSD2 = 0x43
+ } else {
+ return 0x4e;
+ }
+}
+
void meson_canvas_setup(struct meson_drm *priv,
uint32_t canvas_index, uint32_t addr,
uint32_t stride, uint32_t height,
diff --git a/drivers/gpu/drm/meson/meson_canvas.h
b/drivers/gpu/drm/meson/meson_canvas.h
index af1759da4b27..4f594c8a6f80 100644
--- a/drivers/gpu/drm/meson/meson_canvas.h
+++ b/drivers/gpu/drm/meson/meson_canvas.h
@@ -22,8 +22,6 @@
#ifndef __MESON_CANVAS_H
#define __MESON_CANVAS_H
-#define MESON_CANVAS_ID_OSD1 0x4e
-
/* Canvas configuration. */
#define MESON_CANVAS_WRAP_NONE 0x00
#defineMESON_CANVAS_WRAP_X 0x01
@@ -33,6 +31,8 @@
#defineMESON_CANVAS_BLKMODE_32x32 0x01
#defineMESON_CANVAS_BLKMODE_64x64 0x02
+u8 meson_canvas_id_osd1(struct meson_drm *priv);
+
void meson_canvas_setup(struct meson_drm *priv,
uint32_t canvas_index, uint32_t addr,
uint32_t stride, uint32_t height,
diff --git a/drivers/gpu/drm/meson/meson_drv.c
b/drivers/gpu/drm/meson/meson_drv.c
index 3b804fdaf7a0..96c77498ef55 100644
--- a/drivers/gpu/drm/meson/meson_drv.c
+++ b/drivers/gpu/drm/meson/meson_drv.c
@@ -378,6 +378,9 @@ static int meson_drv_probe(struct platform_device *pdev)
};
static const struct of_device_id dt_match[] = {
+ { .compatible = "amlogic,meson8-vpu" },
+ { .compatible = "amlogic,meson8b-vpu" },
+ { .compatible = "amlogic,meson8m2-vpu" },
{ .compatible = "amlogic,meson-gxbb-vpu" },
{ .compatible = "amlogic,meson-gxl-vpu" },
{ .compatible = "amlogic,meson-gxm-vpu" },
diff --git a/drivers/gpu/drm/meson/meson_plane.c
b/drivers/gpu/drm/meson/meson_plane.c
index 17e96fa47868..9d9a491c4eba 100644
--- a/drivers/gpu/drm/meson/meson
[PATCH] fbdev: auo_k190x: Use zeroing memory allocator than allocator/memset
Use vzalloc for allocating zeroed memory and remove unnecessary
memset function.
Done using Coccinelle.
Generated-by: scripts/coccinelle/api/alloc/kzalloc-simple.cocci
0-day tested with no failures.
Suggested-by: Luis R. Rodriguez
Signed-off-by: Himanshu Jha
---
drivers/video/fbdev/auo_k190x.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/auo_k190x.c b/drivers/video/fbdev/auo_k190x.c
index 0d060383..b889401 100644
--- a/drivers/video/fbdev/auo_k190x.c
+++ b/drivers/video/fbdev/auo_k190x.c
@@ -1056,13 +1056,12 @@ int auok190x_common_probe(struct platform_device *pdev,
/* videomemory handling */
videomemorysize = roundup((panel->w * panel->h) * 2, PAGE_SIZE);
- videomemory = vmalloc(videomemorysize);
+ videomemory = vzalloc(videomemorysize);
if (!videomemory) {
ret = -ENOMEM;
goto err_irq;
}
- memset(videomemory, 0, videomemorysize);
info->screen_base = (char *)videomemory;
info->fix.smem_len = videomemorysize;
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH -next] drm/panel: ili9322：Make local symbols static
Fixes the following sparse warnings:
drivers/gpu/drm/panel/panel-ilitek-ili9322.c:182:12: warning:
symbol 'ili9322_inputs' was not declared. Should it be static?
drivers/gpu/drm/panel/panel-ilitek-ili9322.c:343:28: warning:
symbol 'ili9322_regmap_config' was not declared. Should it be static?
Also change ili9322_inputs to 'const char * const' to avoid
chackpatch warning.
Signed-off-by: Wei Yongjun
---
drivers/gpu/drm/panel/panel-ilitek-ili9322.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-ilitek-ili9322.c
b/drivers/gpu/drm/panel/panel-ilitek-ili9322.c
index b4ec0ec..bd38bf4 100644
--- a/drivers/gpu/drm/panel/panel-ilitek-ili9322.c
+++ b/drivers/gpu/drm/panel/panel-ilitek-ili9322.c
@@ -179,7 +179,7 @@ enum ili9322_input {
ILI9322_INPUT_UNKNOWN = 0xc,
};
-const char *ili9322_inputs[] = {
+static const char * const ili9322_inputs[] = {
"8 bit serial RGB through",
"8 bit serial RGB aligned",
"8 bit serial RGB dummy 320x240",
@@ -340,7 +340,7 @@ static bool ili9322_writeable_reg(struct device *dev,
unsigned int reg)
return true;
}
-const struct regmap_config ili9322_regmap_config = {
+static const struct regmap_config ili9322_regmap_config = {
.reg_bits = 8,
.val_bits = 8,
.max_register = 0x44,
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[GIT PULL] Armada DRM (drm-armada-devel-4.15 branch)
David, Please incorporate the latest Armada DRM (drm-armada-devel-4.15 branch), which can be found at: git://git.armlinux.org.uk/~rmk/linux-arm.git drm-armada-devel-4.15 with SHA1 27ab688f70b6f6b51da4bf56b1237f7beb64d847. This series builds upon the set of fixes previously submitted to move Armada DRM closer to atomic modeset. We're nowhere near yet, but this series helps to get us closer by unifying some of the differences between the primary and overlay planes. New features added allows userspace to disable the primary plane if overlay is full screen and there's nothing obscuring the colorkey - this saves having to fetch an entire buffer containing nothing but colorkey when displaying full screen video. This will update the following files: drivers/gpu/drm/armada/armada_crtc.c| 433 +++- drivers/gpu/drm/armada/armada_crtc.h| 26 +- drivers/gpu/drm/armada/armada_overlay.c | 300 +++--- drivers/gpu/drm/armada/armada_trace.h | 24 +- 4 files changed, 494 insertions(+), 289 deletions(-) through these changes: Russell King (29): drm/armada: fix leak of crtc structure drm/armada: fix SRAM powerdown drm/armada: fix UV swap code drm/armada: improve efficiency of armada_drm_plane_calc_addrs() drm/armada: fix YUV planar format framebuffer offsets drm/armada: remove armada_drm_plane_work_cancel() return value drm/armada: add a common frame work allocator drm/armada: store plane in armada_plane_work drm/armada: add work cancel callback drm/armada: wait and cancel any pending frame work at disable drm/armada: allow the primary plane to be disabled drm/armada: clean up armada_drm_crtc_plane_disable() drm/armada: clear plane enable bit when disabling drm/armada: move overlay plane work out from under spinlock drm/armada: move fb retirement into armada_plane_work drm/armada: move event sending into armada_plane_work drm/armada: move regs into armada_plane_work drm/armada: move writes of LCD_SPU_SRAM_PARA1 under lock drm/armada: only enable HSMOOTH if scaling horizontally drm/armada: use drm_plane_helper_check_state() drm/armada: allow armada_drm_plane_work_queue() to silently fail drm/armada: avoid work allocation drm/armada: disable planes at next blanking period drm/armada: re-organise overlay register update generation drm/armada: move overlay plane register update generation drm/armada: wait for previous work when moving overlay window drm/armada: extract register generation from armada_drm_primary_set() drm/armada: implement primary plane update drm/armada: expand overlay trace entry Many thanks. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Cluster-devel] [PATCH 00/12] drop unneeded newline
On Tue, 2018-01-02 at 15:00 +0100, Julia Lawall wrote: > On Tue, 2 Jan 2018, Bob Peterson wrote: > > - Original Message - > > > - Original Message - > > > > > Still, the GFS2 and DLM code has a plethora of broken-up printk messages, > > and I don't like the thought of re-combining them all. > > Actually, the point of the patch was to remove the unnecessary \n at the > end of the string, because log_print will add another one. If you prefer > to keep the string broken up, I can resend the patch in that form, but > without the unnecessary \n. Please combine any user-visible strings into a single line for which the unneeded newline is dropped since these strings are modified anyway by your patch. Thanks, Bart. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/ttm: check the return value of kzalloc
In the function ttm_page_alloc_init, kzalloc call is made for variable
_manager, we need to check its return value, it may return NULL.
Signed-off-by: Xiongwei Song
---
v1->v2: delete kfree _manager
---
drivers/gpu/drm/ttm/ttm_page_alloc.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index b5ba6441489f..583d73edb7df 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -1007,6 +1007,10 @@ int ttm_page_alloc_init(struct ttm_mem_global *glob,
unsigned max_pages)
pr_info("Initializing pool allocator\n");
_manager = kzalloc(sizeof(*_manager), GFP_KERNEL);
+ if (!_manager) {
+ ret = -ENOMEM;
+ goto out;
+ }
ttm_page_pool_init_locked(&_manager->wc_pool, GFP_HIGHUSER, "wc", 0);
@@ -1041,6 +1045,8 @@ int ttm_page_alloc_init(struct ttm_mem_global *glob,
unsigned max_pages)
ttm_pool_mm_shrink_init(_manager);
return 0;
+out:
+ return ret;
}
void ttm_page_alloc_fini(void)
--
2.15.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3] drm/ttm: check the return value of kzalloc
In the function ttm_page_alloc_init, kzalloc call is made for variable
_manager, we need to check its return value, it may return NULL.
Signed-off-by: Xiongwei Song
---
v2->v3: delete goto expression
v1->v2: delete kfree _manager
---
drivers/gpu/drm/ttm/ttm_page_alloc.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index b5ba6441489f..5d252fb27a82 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -1007,6 +1007,8 @@ int ttm_page_alloc_init(struct ttm_mem_global *glob,
unsigned max_pages)
pr_info("Initializing pool allocator\n");
_manager = kzalloc(sizeof(*_manager), GFP_KERNEL);
+ if (!_manager)
+ return -ENOMEM;
ttm_page_pool_init_locked(&_manager->wc_pool, GFP_HIGHUSER, "wc", 0);
--
2.15.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 04/11] drm/bridge/synopsys: dw-hdmi: Export some PHY related functions
Parts of PHY code could be useful also for custom PHYs. For example,
Allwinner A83T has custom PHY which is probably Synopsys gen2 PHY
with few additional memory mapped registers, so most of the Synopsys PHY
related code could be reused.
It turns out that even completely custom HDMI PHYs, such as the one
found in Allwinner H3, can reuse some of those functions. This would
suggest that (some?) functions exported in this commit are actually part
of generic PHY interface and not really specific to Synopsys PHYs.
Export useful PHY functions.
Signed-off-by: Jernej Skrabec
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 45 ++-
drivers/gpu/drm/bridge/synopsys/dw-hdmi.h | 2 ++
include/drm/bridge/dw_hdmi.h | 10 +++
3 files changed, 44 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index 7ca14d7325b5..67467d0b683a 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -1037,19 +1037,21 @@ static void dw_hdmi_phy_enable_svsret(struct dw_hdmi
*hdmi, u8 enable)
HDMI_PHY_CONF0_SVSRET_MASK);
}
-static void dw_hdmi_phy_gen2_pddq(struct dw_hdmi *hdmi, u8 enable)
+void dw_hdmi_phy_gen2_pddq(struct dw_hdmi *hdmi, u8 enable)
{
hdmi_mask_writeb(hdmi, enable, HDMI_PHY_CONF0,
HDMI_PHY_CONF0_GEN2_PDDQ_OFFSET,
HDMI_PHY_CONF0_GEN2_PDDQ_MASK);
}
+EXPORT_SYMBOL_GPL(dw_hdmi_phy_gen2_pddq);
-static void dw_hdmi_phy_gen2_txpwron(struct dw_hdmi *hdmi, u8 enable)
+void dw_hdmi_phy_gen2_txpwron(struct dw_hdmi *hdmi, u8 enable)
{
hdmi_mask_writeb(hdmi, enable, HDMI_PHY_CONF0,
HDMI_PHY_CONF0_GEN2_TXPWRON_OFFSET,
HDMI_PHY_CONF0_GEN2_TXPWRON_MASK);
}
+EXPORT_SYMBOL_GPL(dw_hdmi_phy_gen2_txpwron);
static void dw_hdmi_phy_sel_data_en_pol(struct dw_hdmi *hdmi, u8 enable)
{
@@ -1065,6 +1067,23 @@ static void dw_hdmi_phy_sel_interface_control(struct
dw_hdmi *hdmi, u8 enable)
HDMI_PHY_CONF0_SELDIPIF_MASK);
}
+void dw_hdmi_phy_gen2_reset(struct dw_hdmi *hdmi, u8 enable)
+{
+ hdmi_mask_writeb(hdmi, enable, HDMI_MC_PHYRSTZ,
+HDMI_MC_PHYRSTZ_PHYRSTZ_OFFSET,
+HDMI_MC_PHYRSTZ_PHYRSTZ_MASK);
+}
+EXPORT_SYMBOL_GPL(dw_hdmi_phy_gen2_reset);
+
+void dw_hdmi_phy_set_slave_addr(struct dw_hdmi *hdmi)
+{
+ hdmi_phy_test_clear(hdmi, 1);
+ hdmi_writeb(hdmi, HDMI_PHY_I2CM_SLAVE_ADDR_PHY_GEN2,
+ HDMI_PHY_I2CM_SLAVE_ADDR);
+ hdmi_phy_test_clear(hdmi, 0);
+}
+EXPORT_SYMBOL_GPL(dw_hdmi_phy_set_slave_addr);
+
static void dw_hdmi_phy_power_off(struct dw_hdmi *hdmi)
{
const struct dw_hdmi_phy_data *phy = hdmi->phy.data;
@@ -1204,15 +1223,12 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi)
dw_hdmi_phy_enable_svsret(hdmi, 1);
/* PHY reset. The reset signal is active high on Gen2 PHYs. */
- hdmi_writeb(hdmi, HDMI_MC_PHYRSTZ_PHYRSTZ, HDMI_MC_PHYRSTZ);
- hdmi_writeb(hdmi, 0, HDMI_MC_PHYRSTZ);
+ dw_hdmi_phy_gen2_reset(hdmi, 1);
+ dw_hdmi_phy_gen2_reset(hdmi, 0);
hdmi_writeb(hdmi, HDMI_MC_HEACPHY_RST_ASSERT, HDMI_MC_HEACPHY_RST);
- hdmi_phy_test_clear(hdmi, 1);
- hdmi_writeb(hdmi, HDMI_PHY_I2CM_SLAVE_ADDR_PHY_GEN2,
- HDMI_PHY_I2CM_SLAVE_ADDR);
- hdmi_phy_test_clear(hdmi, 0);
+ dw_hdmi_phy_set_slave_addr(hdmi);
/* Write to the PHY as configured by the platform */
if (pdata->configure_phy)
@@ -1251,15 +1267,16 @@ static void dw_hdmi_phy_disable(struct dw_hdmi *hdmi,
void *data)
dw_hdmi_phy_power_off(hdmi);
}
-static enum drm_connector_status dw_hdmi_phy_read_hpd(struct dw_hdmi *hdmi,
- void *data)
+enum drm_connector_status dw_hdmi_phy_read_hpd(struct dw_hdmi *hdmi,
+ void *data)
{
return hdmi_readb(hdmi, HDMI_PHY_STAT0) & HDMI_PHY_HPD ?
connector_status_connected : connector_status_disconnected;
}
+EXPORT_SYMBOL_GPL(dw_hdmi_phy_read_hpd);
-static void dw_hdmi_phy_update_hpd(struct dw_hdmi *hdmi, void *data,
- bool force, bool disabled, bool rxsense)
+void dw_hdmi_phy_update_hpd(struct dw_hdmi *hdmi, void *data,
+ bool force, bool disabled, bool rxsense)
{
u8 old_mask = hdmi->phy_mask;
@@ -1271,8 +1288,9 @@ static void dw_hdmi_phy_update_hpd(struct dw_hdmi *hdmi,
void *data,
if (old_mask != hdmi->phy_mask)
hdmi_writeb(hdmi, hdmi->phy_mask, HDMI_PHY_MASK0);
}
+EXPORT_SYMBOL_GPL(dw_hdmi_phy_update_hpd);
-static void dw_hdmi_phy_setup_hpd(struct dw_hdmi *hdmi, void *data)
+void dw_hdmi_phy_setup_hpd(struct dw_hdmi *hdmi, void *data)
{
/*
* Configur
Re: [PATCH 01/33] clk_ops: change round_rate() to return unsigned long
FWIW, we had this problem some years ago with the Tegra CPU clock - then it was determined that a simpler solution was to have the determine_rate callback support unsigned long rates - so clock drivers that need to return rates higher than 2^31 can instead implement the determine_rate callback. That is what's currently implemented. Mikko On 12/30/2017 03:12 AM, Bryan O'Donoghue wrote: Right now it is not possible to return a value larger than LONG_MAX on 32 bit systems. You can pass a rate of ULONG_MAX but can't return anything past LONG_MAX due to the fact both the rounded_rate and negative error codes are represented in the return value of round_rate(). Most implementations either return zero on error or don't return error codes at all. A minority of implementations do return a negative number - typically -EINVAL or -ENODEV. At the higher level then callers of round_rate() typically and rightly check for a value of <= 0. It is possible then to convert round_rate() to an unsigned long return value and change error code indication for the minority from -ERRORCODE to a simple 0. This patch is the first step in making it possible to scale round_rate past LONG_MAX, later patches will change the previously mentioned minority of round_rate() implementations to return zero only on error if those implementations currently return a negative error number. Implementations that do not return an error code of < 0 will be left as-is. Signed-off-by: Bryan O'Donoghue Cc: Michael Turquette Cc: Stephen Boyd Cc: linux-o...@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org Cc: linux-ker...@vger.kernel.org Cc: linux-m...@linux-mips.org Cc: linux-...@vger.kernel.org Cc: linux-rpi-ker...@lists.infradead.org Cc: patc...@opensource.cirrus.com Cc: uclinux-h8-de...@lists.sourceforge.jp Cc: linux-amlo...@lists.infradead.org Cc: linux-arm-...@vger.kernel.org Cc: linux-...@vger.kernel.org Cc: linux-renesas-...@vger.kernel.org Cc: linux-rockc...@lists.infradead.org Cc: linux-samsung-...@vger.kernel.org Cc: linux-te...@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Cc: linux-media...@lists.infradead.org Cc: freedr...@lists.freedesktop.org Cc: linux-me...@vger.kernel.org Cc: linux-...@vger.kernel.org --- arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c| 4 ++-- arch/arm/mach-omap2/clock2xxx.h | 4 ++-- arch/arm/mach-vexpress/spc.c| 4 ++-- arch/mips/alchemy/common/clock.c| 2 +- drivers/clk/at91/clk-audio-pll.c| 10 ++ drivers/clk/at91/clk-h32mx.c| 5 +++-- drivers/clk/at91/clk-peripheral.c | 6 +++--- drivers/clk/at91/clk-pll.c | 2 +- drivers/clk/at91/clk-plldiv.c | 5 +++-- drivers/clk/at91/clk-smd.c | 5 +++-- drivers/clk/at91/clk-usb.c | 5 +++-- drivers/clk/axs10x/i2s_pll_clock.c | 4 ++-- drivers/clk/axs10x/pll_clock.c | 5 +++-- drivers/clk/bcm/clk-bcm2835.c | 11 ++- drivers/clk/bcm/clk-iproc-asiu.c| 5 +++-- drivers/clk/bcm/clk-iproc-pll.c | 8 drivers/clk/clk-axi-clkgen.c| 5 +++-- drivers/clk/clk-cdce706.c | 15 +-- drivers/clk/clk-cdce925.c | 15 +-- drivers/clk/clk-composite.c | 5 +++-- drivers/clk/clk-cs2000-cp.c | 4 ++-- drivers/clk/clk-divider.c | 5 +++-- drivers/clk/clk-fixed-factor.c | 5 +++-- drivers/clk/clk-fractional-divider.c| 4 ++-- drivers/clk/clk-gemini.c| 5 +++-- drivers/clk/clk-highbank.c | 10 ++ drivers/clk/clk-hsdk-pll.c | 4 ++-- drivers/clk/clk-multiplier.c| 5 +++-- drivers/clk/clk-scpi.c | 8 drivers/clk/clk-si514.c | 4 ++-- drivers/clk/clk-si5351.c| 15 +-- drivers/clk/clk-si570.c | 4 ++-- drivers/clk/clk-stm32f4.c | 15 +-- drivers/clk/clk-u300.c | 4 ++-- drivers/clk/clk-versaclock5.c | 12 ++-- drivers/clk/clk-vt8500.c| 9 + drivers/clk/clk-wm831x.c| 5 +++-- drivers/clk/clk-xgene.c | 9 + drivers/clk/h8300/clk-h8s2678.c | 4 ++-- drivers/clk/hisilicon/clk-hi6220-stub.c | 5 +++-- drivers/clk/hisilicon/clkdivider-hi6220.c | 5 +++-- drivers/clk/imx/clk-busy.c | 5 +++-- drivers/clk/imx/clk-cpu.c | 4 ++-- drivers/clk/imx/clk-fixup-div.c | 5 +++-- drivers/clk/i
[GIT PULL] Armada DRM (drm-armada-fixes-4.15 branch)
David, Please incorporate the latest Armada DRM (drm-armada-fixes-4.15 branch), which can be found at: git://git.armlinux.org.uk/~rmk/linux-arm.git drm-armada-fixes-4.15 with SHA1 de0ea9ad2f548dd9e555cac27cf7ade1db5b26ea. As previously posted to dri-devel. Apart from some feedback on the initial patch on 29th November, no other comments, reviewed-by or acks have been forthcoming despite re-posting. Being fixes, these are for 4.15-rc series kernels. This will update the following files: drivers/gpu/drm/armada/armada_crtc.c| 47 +++-- drivers/gpu/drm/armada/armada_crtc.h| 2 ++ drivers/gpu/drm/armada/armada_overlay.c | 38 +- 3 files changed, 48 insertions(+), 39 deletions(-) through these changes: Russell King (5): drm/armada: fix leak of crtc structure drm/armada: fix SRAM powerdown drm/armada: fix UV swap code drm/armada: improve efficiency of armada_drm_plane_calc_addrs() drm/armada: fix YUV planar format framebuffer offsets Many thanks. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 02/11] clk: sunxi-ng: a83t: Add M divider to TCON1 clock
TCON1 also has M divider, contrary to TCON0.
Fixes: 05359be1176b ("clk: sunxi-ng: Add driver for A83T CCU")
Signed-off-by: Jernej Skrabec
---
drivers/clk/sunxi-ng/ccu-sun8i-a83t.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-a83t.c
b/drivers/clk/sunxi-ng/ccu-sun8i-a83t.c
index 04a9c33f53f0..7d08015b980d 100644
--- a/drivers/clk/sunxi-ng/ccu-sun8i-a83t.c
+++ b/drivers/clk/sunxi-ng/ccu-sun8i-a83t.c
@@ -504,8 +504,8 @@ static SUNXI_CCU_MUX_WITH_GATE(tcon0_clk, "tcon0",
tcon0_parents,
0x118, 24, 3, BIT(31), CLK_SET_RATE_PARENT);
static const char * const tcon1_parents[] = { "pll-video1" };
-static SUNXI_CCU_MUX_WITH_GATE(tcon1_clk, "tcon1", tcon1_parents,
-0x11c, 24, 3, BIT(31), CLK_SET_RATE_PARENT);
+static SUNXI_CCU_M_WITH_MUX_GATE(tcon1_clk, "tcon1", tcon1_parents,
+0x11c, 0, 4, 24, 2, BIT(31),
CLK_SET_RATE_PARENT);
static SUNXI_CCU_GATE(csi_misc_clk, "csi-misc", "osc24M", 0x130, BIT(16), 0);
--
2.15.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC HACK 1/2] gpu: drm: meson: HACK - Meson8/Meson8b/Meson8m2 support - WiP
Hi Neil,
On Tue, Jan 2, 2018 at 12:01 PM, Neil Armstrong wrote:
> Hi Martin,
>
> Thanks for the research !!!
you're welcome - I'm slowly starting to understand why implementing
video drivers takes a long time...
> Let me clarify this OSD1/2 stuff.
>
> There is 2 OSD planes (that can get single-buffer input), and 2 Video plane
> that can get multi-planar video like YUV or NV12.
> Only the OSD1 is enabled since it needs the Super Scaler in passthrought to
> automatically change the interlace field needed when you output in interlace
> mode on CVBS.
>
> So :
> - the OSD1 needs a CANVAS id where to get the data from, with other infos in
> the VIU_OSD1_BLK0_CFG_W0 reg
this matches with what I've seen: if I undo that canvas ID change then
the image from u-boot is visible ("fbv test-image.png" does not draw
over it or clear it)
> - the CANVAS id is only a logical id to define an entry in the CANVAS Manager
> where you can store every planes, so you only change the CANVAS ID in the
> VIU_OSD1_BLK0_CFG_W0 reg
> - the Super Scaler needs a source to be configured from, my code is
> incorrect, I should not enable BIT(2), bits 0-1 should be 0
so VPP_OSD_SC_CTRL0 is "VPP OSD Super Scaler Control 0"
> - The VPP_MISC register describes which OSD is enabled, and en eventual
> ordering, you may check in the kernel source if this register layout is the
> same
the documentation in
uboot-2015-01-15-23a3562521/arch/arm/include/asm/arch-m8/register.h
for the VPP_MISC matches the documentation that can be found in
Khadas' GXM (S912) datasheet
> Looking at your code, you seem to still use ISD1, and only change a virtual
> logical CANVAS id, and you changed the Super Scaler register to use OSD2 as
> source, but it may be disabled.
actually my code *should* change it to OSD2:
writel_relaxed(BIT(3) /* Enable scaler */ |
BIT(0), /* Select OSD2 - FIXME */
priv->io_base + _REG(VPP_OSD_SC_CTRL0));
which matches OSD2 from your description:
- 00: select osd1 input
- 01: select osd2 input
- 10: select vd1 input
- 11: select vd2 input after matrix
maybe I tricked you with the name meson_canvas_id_osd1() - a better
name would have been meson_canvas_id_HACK():
return 0x43; // HACK: OSD1 = 0x40, OSD2 = 0x43
so I'm actually returning the ID for OSD2 (I took these OSD IDs from
uboot-2015-01-15-23a3562521/arch/arm/include/asm/arch-m8/canvas.h)
> Neil
>
> On 01/01/2018 22:35, Martin Blumenstingl wrote:
>> TODO:
>> - canvas registers offsets on Meson8 / Meson8b are different
>> - hardcoded register values
>> - OSD2 is used for CVBS on Meson8 (at least on Meson8m2)
>>
>> Signed-off-by: Martin Blumenstingl
>> ---
>> .../bindings/display/amlogic,meson-vpu.txt | 18 +-
>> drivers/gpu/drm/meson/meson_canvas.c | 11 +
>> drivers/gpu/drm/meson/meson_canvas.h | 4 ++--
>> drivers/gpu/drm/meson/meson_drv.c | 3 +++
>> drivers/gpu/drm/meson/meson_plane.c| 5 ++--
>> drivers/gpu/drm/meson/meson_vclk.c | 21 ++--
>> drivers/gpu/drm/meson/meson_venc_cvbs.c| 5 +++-
>> drivers/gpu/drm/meson/meson_viu.c | 5 +++-
>> drivers/gpu/drm/meson/meson_vpp.c | 28
>> ++
>> 9 files changed, 86 insertions(+), 14 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/display/amlogic,meson-vpu.txt
>> b/Documentation/devicetree/bindings/display/amlogic,meson-vpu.txt
>> index 00f74bad1e95..f416cdc88f25 100644
>> --- a/Documentation/devicetree/bindings/display/amlogic,meson-vpu.txt
>> +++ b/Documentation/devicetree/bindings/display/amlogic,meson-vpu.txt
>> @@ -53,6 +53,9 @@ VPU: Video Processing Unit
>>
>> Required properties:
>> - compatible: value should be different for each SoC family as :
>> + - Meson8 (S802) : "amlogic,meson8-vpu"
>> + - Meson8b (S805) : "amlogic,meson8b-vpu"
>> + - Meson8m2 (S812) : "amlogic,meson8m2-vpu"
>> - GXBB (S905) : "amlogic,meson-gxbb-vpu"
>> - GXL (S905X, S905D) : "amlogic,meson-gxl-vpu"
>> - GXM (S912) : "amlogic,meson-gxm-vpu"
>> @@ -72,12 +75,15 @@ bindings specified in
>> Documentation/devicetree/bindings/graph.txt.
>> The following table lists for each supported model the port number
>> corresponding to each VPU output.
>>
>> - Port 0 Port 1
>> --
>> - S905 (GXBB) CVBS VDAC HDMI-TX
>> - S905X (GXL) CVBS VDAC HDMI-TX
>> - S905D (GXL) CVBS VDAC HDMI-TX
>> - S912 (GXM) CVBS VDAC HDMI-TX
>> + Port 0 Port 1
>> +---
>> + S802 (Meson8) CVBS VDAC not implemented yet
>> + S805 (Meson8b) CVBS VDAC not implemented yet
>> + S812 (Meson8m2) CVBS VDAC not implemented yet
>
> Maybe N/A is better.
>
>> + S905 (GXBB) CVBS VDAC HDMI
Re: [PATCH V4 24/26] video: fbdev: riva: deprecate pci_get_bus_and_slot()
On 12/19/2017 12:38 AM, Sinan Kaya wrote: > pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as > where a PCI device is present. This restricts the device drivers to be > reused for other domain numbers. > > Getting ready to remove pci_get_bus_and_slot() function in favor of > pci_get_domain_bus_and_slot(). > > struct riva_par has a pointer to struct pci_dev. Use the pci_dev member > to extract the domain information. > > Change the function signature for CalcStateExt and RivaGetConfig to pass > in struct pci_dev in addition to RIVA_HW_INST so that code inside the > riva_hw.c can also calculate domain number and pass it to > pci_get_domain_bus_and_slot(). > > Signed-off-by: Sinan Kaya Any feedback here, most of the remaining patches have the ACK except these? -- Sinan Kaya Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 10/11] ARM: dts: sun8i: a83t: Add HDMI display pipeline
This commit adds all bits necessary for HDMI on A83T - mixer1, tcon1,
hdmi and hdmi pinctrl entries.
Signed-off-by: Jernej Skrabec
---
arch/arm/boot/dts/sun8i-a83t.dtsi | 108 +-
1 file changed, 107 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi
b/arch/arm/boot/dts/sun8i-a83t.dtsi
index 7f4955a5fab7..601d1eb5460e 100644
--- a/arch/arm/boot/dts/sun8i-a83t.dtsi
+++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
@@ -155,7 +155,7 @@
de: display-engine {
compatible = "allwinner,sun8i-a83t-display-engine";
- allwinner,pipelines = <&mixer0>;
+ allwinner,pipelines = <&mixer0>, <&mixer1>;
status = "disabled";
};
@@ -208,6 +208,32 @@
};
};
+ mixer1: mixer@120 {
+ compatible = "allwinner,sun8i-a83t-de2-mixer-1";
+ reg = <0x0120 0x10>;
+ clocks = <&display_clocks CLK_BUS_MIXER1>,
+<&display_clocks CLK_MIXER1>;
+ clock-names = "bus",
+ "mod";
+ resets = <&display_clocks RST_WB>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ mixer1_out: port@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+
+ mixer1_out_tcon1: endpoint@0 {
+ reg = <0>;
+ remote-endpoint =
<&tcon1_in_mixer1>;
+ };
+ };
+ };
+ };
+
syscon: syscon@1c0 {
compatible = "allwinner,sun8i-a83t-system-controller",
"syscon";
@@ -256,6 +282,43 @@
};
};
+ tcon1: lcd-controller@1c0d000 {
+ compatible = "allwinner,sun8i-a83t-tcon-tv";
+ reg = <0x01c0d000 0x1000>;
+ interrupts = ;
+ clocks = <&ccu CLK_BUS_TCON1>, <&ccu CLK_TCON1>;
+ clock-names = "ahb", "tcon-ch1";
+ resets = <&ccu RST_BUS_TCON1>;
+ reset-names = "lcd";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ tcon1_in: port@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+
+ tcon1_in_mixer1: endpoint@0 {
+ reg = <0>;
+ remote-endpoint =
<&mixer1_out_tcon1>;
+ };
+ };
+
+ tcon1_out: port@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+
+ tcon1_out_hdmi: endpoint@1 {
+ reg = <1>;
+ remote-endpoint =
<&hdmi_in_tcon1>;
+ };
+ };
+ };
+ };
+
mmc0: mmc@1c0f000 {
compatible = "allwinner,sun8i-a83t-mmc",
"allwinner,sun7i-a20-mmc";
@@ -427,6 +490,11 @@
drive-strength = <40>;
};
+ hdmi_pins: hdmi-pins {
+ pins = "PH6", "PH7", "PH8";
+ function = "hdmi";
+ };
+
i2c0_pins: i2c0-pins {
pins = "PH0", "PH1";
function = "i2c0";
@@ -685,6 +753,44 @@
interrupts = ;
};
+ hdmi: hdmi@1ee {
+ compatible = "allwinner,sun8i-a83t-dw-hdmi";
+ reg = <0x01ee 0x1>,
+ <0x01ef 0x1>;
+ reg-io-width = <1>;
+ interrupts = ;
+ clocks = <&ccu CLK_BUS_HDMI>, <&ccu CLK_HDMI_SLOW>,
+<&ccu CLK_HDMI>;
+
[nouveau] grumble/gripe ... fifo: read fault ... channel 12 killed! (eternal freeze-frame)
Twice now with v4.15-rc6, my display has gone belly up. Note: swiotlb: suppress warning when __GFP_NOWARN is set v2 is applied, but I don't _think_ it was the first time it happened. [ 3729.558261] nouveau :01:00.0: gr: TRAP ch 2 [00ff842000 Xorg[3413]] [ 3729.558269] nouveau :01:00.0: gr: GPC0/TPC0/TEX: 8041 [ 3729.558273] nouveau :01:00.0: gr: GPC0/TPC1/TEX: 8041 [ 3729.558277] nouveau :01:00.0: gr: GPC0/TPC2/TEX: 8041 [ 3729.558280] nouveau :01:00.0: gr: GPC0/TPC3/TEX: 8041 [ 3729.558286] nouveau :01:00.0: gr: GPC1/TPC0/TEX: 8041 [ 3729.558289] nouveau :01:00.0: gr: GPC1/TPC1/TEX: 8041 [ 3729.558293] nouveau :01:00.0: gr: GPC1/TPC2/TEX: 8041 [ 3729.558297] nouveau :01:00.0: gr: GPC1/TPC3/TEX: 8041 [ 3729.558302] nouveau :01:00.0: gr: GPC2/TPC0/TEX: 8041 [ 3729.558305] nouveau :01:00.0: gr: GPC2/TPC1/TEX: 8041 [ 3729.558309] nouveau :01:00.0: gr: GPC2/TPC2/TEX: 8041 [ 3729.558313] nouveau :01:00.0: gr: GPC2/TPC3/TEX: 8041 [ 3729.558318] nouveau :01:00.0: gr: GPC3/TPC0/TEX: 8041 [ 3729.558322] nouveau :01:00.0: gr: GPC3/TPC1/TEX: 8041 [ 3729.558325] nouveau :01:00.0: gr: GPC3/TPC2/TEX: 8041 [ 3729.558329] nouveau :01:00.0: gr: GPC3/TPC3/TEX: 8041 [ 3729.558336] nouveau :01:00.0: fifo: read fault at 000a9dd000 engine 00 [GR] client 0a [GPC2/T1_3] reason 02 [PTE] on channel 2 [00ff842000 Xorg[3413]] [ 3729.558341] nouveau :01:00.0: fifo: channel 2: killed [ 3729.558343] nouveau :01:00.0: fifo: runlist 0: scheduled for recovery [ 3729.558346] nouveau :01:00.0: fifo: engine 0: scheduled for recovery [ 3729.558352] nouveau :01:00.0: fifo: engine 7: scheduled for recovery [ 3729.558355] nouveau :01:00.0: Xorg[3413]: channel 2 killed! [ 3729.562994] nouveau :01:00.0: gr: TRAP ch 12 [00fd2d6000 plasmashell[3898]] [ 3729.563011] nouveau :01:00.0: gr: GPC0/TPC0/TEX: 8041 [ 3729.563015] nouveau :01:00.0: gr: GPC0/TPC1/TEX: 8041 [ 3729.563018] nouveau :01:00.0: gr: GPC0/TPC2/TEX: 8041 [ 3729.563022] nouveau :01:00.0: gr: GPC0/TPC3/TEX: 8041 [ 3729.563027] nouveau :01:00.0: gr: GPC1/TPC0/TEX: 8041 [ 3729.563031] nouveau :01:00.0: gr: GPC1/TPC1/TEX: 8041 [ 3729.563034] nouveau :01:00.0: gr: GPC1/TPC2/TEX: 8041 [ 3729.563038] nouveau :01:00.0: gr: GPC1/TPC3/TEX: 8041 [ 3729.563043] nouveau :01:00.0: gr: GPC2/TPC0/TEX: 8041 [ 3729.563047] nouveau :01:00.0: gr: GPC2/TPC1/TEX: 8041 [ 3729.563050] nouveau :01:00.0: gr: GPC2/TPC2/TEX: 8041 [ 3729.563054] nouveau :01:00.0: gr: GPC2/TPC3/TEX: 8041 [ 3729.563059] nouveau :01:00.0: gr: GPC3/TPC0/TEX: 8041 [ 3729.563063] nouveau :01:00.0: gr: GPC3/TPC1/TEX: 8041 [ 3729.563066] nouveau :01:00.0: gr: GPC3/TPC2/TEX: 8041 [ 3729.563070] nouveau :01:00.0: gr: GPC3/TPC3/TEX: 8041 [ 3729.563078] nouveau :01:00.0: fifo: read fault at 0004be4000 engine 00 [GR] client 01 [GPC0/T1_0] reason 02 [PTE] on channel 12 [00fd2d6000 plasmashell[3898]] [ 3729.563083] nouveau :01:00.0: fifo: channel 12: killed [ 3729.563085] nouveau :01:00.0: fifo: runlist 0: scheduled for recovery [ 3729.563089] nouveau :01:00.0: fifo: engine 0: scheduled for recovery [ 3729.563092] nouveau :01:00.0: plasmashell[3898]: channel 12 killed! ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 07/11] drm/sun4i: Add support for A83T second TCON
This TCON doesn't have channel 0, so quirk has_channel_0 is added in the
process.
Signed-off-by: Jernej Skrabec
---
drivers/gpu/drm/sun4i/sun4i_tcon.c | 46 --
drivers/gpu/drm/sun4i/sun4i_tcon.h | 1 +
2 files changed, 35 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index b78fed809992..adfa39f372cf 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -84,6 +84,7 @@ static void sun4i_tcon_channel_set_status(struct sun4i_tcon
*tcon, int channel,
switch (channel) {
case 0:
+ WARN_ON(!tcon->quirks->has_channel_0);
regmap_update_bits(tcon->regs, SUN4I_TCON0_CTL_REG,
SUN4I_TCON0_CTL_TCON_ENABLE,
enabled ? SUN4I_TCON0_CTL_TCON_ENABLE : 0);
@@ -276,6 +277,8 @@ static void sun4i_tcon0_mode_set_lvds(struct sun4i_tcon
*tcon,
u8 clk_delay;
u32 reg, val = 0;
+ WARN_ON(!tcon->quirks->has_channel_0);
+
tcon->dclk_min_div = 7;
tcon->dclk_max_div = 7;
sun4i_tcon0_mode_set_common(tcon, mode);
@@ -344,6 +347,8 @@ static void sun4i_tcon0_mode_set_rgb(struct sun4i_tcon
*tcon,
u8 clk_delay;
u32 val = 0;
+ WARN_ON(!tcon->quirks->has_channel_0);
+
tcon->dclk_min_div = 6;
tcon->dclk_max_div = 127;
sun4i_tcon0_mode_set_common(tcon, mode);
@@ -570,10 +575,12 @@ static int sun4i_tcon_init_clocks(struct device *dev,
}
clk_prepare_enable(tcon->clk);
- tcon->sclk0 = devm_clk_get(dev, "tcon-ch0");
- if (IS_ERR(tcon->sclk0)) {
- dev_err(dev, "Couldn't get the TCON channel 0 clock\n");
- return PTR_ERR(tcon->sclk0);
+ if (tcon->quirks->has_channel_0) {
+ tcon->sclk0 = devm_clk_get(dev, "tcon-ch0");
+ if (IS_ERR(tcon->sclk0)) {
+ dev_err(dev, "Couldn't get the TCON channel 0 clock\n");
+ return PTR_ERR(tcon->sclk0);
+ }
}
if (tcon->quirks->has_channel_1) {
@@ -930,10 +937,12 @@ static int sun4i_tcon_bind(struct device *dev, struct
device *master,
goto err_free_clocks;
}
- ret = sun4i_dclk_create(dev, tcon);
- if (ret) {
- dev_err(dev, "Couldn't create our TCON dot clock\n");
- goto err_free_clocks;
+ if (tcon->quirks->has_channel_0) {
+ ret = sun4i_dclk_create(dev, tcon);
+ if (ret) {
+ dev_err(dev, "Couldn't create our TCON dot clock\n");
+ goto err_free_clocks;
+ }
}
ret = sun4i_tcon_init_irq(dev, tcon);
@@ -991,7 +1000,8 @@ static int sun4i_tcon_bind(struct device *dev, struct
device *master,
return 0;
err_free_dotclock:
- sun4i_dclk_free(tcon);
+ if (tcon->quirks->has_channel_0)
+ sun4i_dclk_free(tcon);
err_free_clocks:
sun4i_tcon_free_clocks(tcon);
err_assert_reset:
@@ -1005,7 +1015,8 @@ static void sun4i_tcon_unbind(struct device *dev, struct
device *master,
struct sun4i_tcon *tcon = dev_get_drvdata(dev);
list_del(&tcon->list);
- sun4i_dclk_free(tcon);
+ if (tcon->quirks->has_channel_0)
+ sun4i_dclk_free(tcon);
sun4i_tcon_free_clocks(tcon);
}
@@ -1102,16 +1113,19 @@ static int sun6i_tcon_set_mux(struct sun4i_tcon *tcon,
}
static const struct sun4i_tcon_quirks sun4i_a10_quirks = {
+ .has_channel_0 = true,
.has_channel_1 = true,
.set_mux= sun4i_a10_tcon_set_mux,
};
static const struct sun4i_tcon_quirks sun5i_a13_quirks = {
+ .has_channel_0 = true,
.has_channel_1 = true,
.set_mux= sun5i_a13_tcon_set_mux,
};
static const struct sun4i_tcon_quirks sun6i_a31_quirks = {
+ .has_channel_0 = true,
.has_channel_1 = true,
.has_lvds_alt = true,
.needs_de_be_mux= true,
@@ -1119,26 +1133,33 @@ static const struct sun4i_tcon_quirks sun6i_a31_quirks
= {
};
static const struct sun4i_tcon_quirks sun6i_a31s_quirks = {
+ .has_channel_0 = true,
.has_channel_1 = true,
.needs_de_be_mux= true,
};
static const struct sun4i_tcon_quirks sun7i_a20_quirks = {
+ .has_channel_0 = true,
.has_channel_1 = true,
/* Same display pipeline structure as A10 */
.set_mux= sun4i_a10_tcon_set_mux,
};
static const struct sun4i_tcon_quirks sun8i_a33_quirks = {
+ .has_channel_0 = true,
.has_lvds_alt = true,
};
static const struct sun4i_tcon_quirks sun8i_a83t_lcd_quirks = {
- /* nothing is supported */
+ .has_channel_0
Re: [PATCH v3 00/27] kill devm_ioremap_nocache
+ cris/ia64/mn10300/openrisc maintainers On 2017/12/25 9:09, Yisheng Xie wrote: > hi Christophe and Greg, > > On 2017/12/24 16:55, christophe leroy wrote: >> >> >> Le 23/12/2017 à 16:57, Guenter Roeck a écrit : >>> On 12/23/2017 05:48 AM, Greg KH wrote: On Sat, Dec 23, 2017 at 06:55:25PM +0800, Yisheng Xie wrote: > Hi all, > > When I tried to use devm_ioremap function and review related code, I found > devm_ioremap and devm_ioremap_nocache is almost the same with each other, > except one use ioremap while the other use ioremap_nocache. For all arches? Really? Look at MIPS, and x86, they have different functions. >>> >>> Both mips and x86 end up mapping the same function, but other arches don't. >>> mn10300 is one where ioremap and ioremap_nocache are definitely different. >> >> alpha: identical >> arc: identical >> arm: identical >> arm64: identical >> cris: different<== >> frv: identical >> hexagone: identical >> ia64: different<== >> m32r: identical >> m68k: identical >> metag: identical >> microblaze: identical >> mips: identical >> mn10300: different <== >> nios: identical >> openrisc: different<== >> parisc: identical >> riscv: identical >> s390: identical >> sh: identical >> sparc: identical >> tile: identical >> um: rely on asm/generic >> unicore32: identical >> x86: identical >> asm/generic (no mmu): identical > > Wow, that's correct, sorry for I have just checked the main archs, I means > x86,arm, arm64, mips. > > However, I stall have no idea about why these 4 archs want different ioremap > function with others. Drivers seems cannot aware this? If driver call ioremap > want he really want for there 4 archs, cache or nocache? Could you please help about this? it is out of my knowledge. Thanks Yisheng > >> >> So 4 among all arches seems to have ioremap() and ioremap_nocache() being >> different. >> >> Could we have a define set by the 4 arches on which ioremap() and >> ioremap_nocache() are different, something like >> HAVE_DIFFERENT_IOREMAP_NOCACHE ? > > Then, what the HAVE_DIFFERENT_IOREMAP_NOCACHE is uesed for ? > > Thanks > Yisheng >> >> Christophe >> >>> >>> Guenter >>> > While ioremap's > default function is ioremap_nocache, so devm_ioremap_nocache also have the > same function with devm_ioremap, which can just be killed to reduce the > size > of devres.o(from 20304 bytes to 18992 bytes in my compile environment). > > I have posted two versions, which use macro instead of function for > devm_ioremap_nocache[1] or devm_ioremap[2]. And Greg suggest me to kill > devm_ioremap_nocache for no need to keep a macro around for the duplicate > thing. So here comes v3 and please help to review. I don't think this can be done, what am I missing? These functions are not identical, sorry for missing that before. > > Never mind, I should checked all the arches, sorry about that. > thanks, greg k-h >>> >>> -- >>> To unsubscribe from this list: send the line "unsubscribe linux-watchdog" in >>> the body of a message to majord...@vger.kernel.org >>> More majordomo info at http://vger.kernel.org/majordomo-info.html >> >> --- >> L'absence de virus dans ce courrier électronique a été vérifiée par le >> logiciel antivirus Avast. >> https://www.avast.com/antivirus >> >> >> . >> > > > . > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/omap: plane zpos/zorder management improvements
Use the plane index as default zpos for all planes. Even if the
application is not setting zpos/zorder explicitly we will have unique zpos
for each plane.
Enforce that all planes must have unique zpos by refusing atomic update for
planes with already used zpos.
Signed-off-by: Peter Ujfalusi
---
Hi,
changes since v1:
- Dropped the zpos normalization related patches
- New patch based on the discussion, see commit message.
Regards,
Peter
drivers/gpu/drm/omapdrm/omap_plane.c | 26 +++---
1 file changed, 19 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_plane.c
b/drivers/gpu/drm/omapdrm/omap_plane.c
index 15e5d5d325c6..6aeda3cc2f8b 100644
--- a/drivers/gpu/drm/omapdrm/omap_plane.c
+++ b/drivers/gpu/drm/omapdrm/omap_plane.c
@@ -33,6 +33,7 @@
struct omap_plane {
struct drm_plane base;
enum omap_plane_id id;
+ int idx;
const char *name;
};
@@ -99,8 +100,7 @@ static void omap_plane_atomic_disable(struct drm_plane
*plane,
struct omap_plane *omap_plane = to_omap_plane(plane);
plane->state->rotation = DRM_MODE_ROTATE_0;
- plane->state->zpos = plane->type == DRM_PLANE_TYPE_PRIMARY
- ? 0 : omap_plane->id;
+ plane->state->zpos = omap_plane->idx;
priv->dispc_ops->ovl_enable(omap_plane->id, false);
}
@@ -109,15 +109,17 @@ static int omap_plane_atomic_check(struct drm_plane
*plane,
struct drm_plane_state *state)
{
struct drm_crtc_state *crtc_state;
+ struct drm_crtc *crtc = state->crtc;
+ struct drm_plane *p;
if (!state->fb)
return 0;
/* crtc should only be NULL when disabling (i.e., !state->fb) */
- if (WARN_ON(!state->crtc))
+ if (WARN_ON(!crtc))
return 0;
- crtc_state = drm_atomic_get_existing_crtc_state(state->state,
state->crtc);
+ crtc_state = drm_atomic_get_existing_crtc_state(state->state, crtc);
/* we should have a crtc state if the plane is attached to a crtc */
if (WARN_ON(!crtc_state))
return 0;
@@ -125,6 +127,16 @@ static int omap_plane_atomic_check(struct drm_plane *plane,
if (!crtc_state->enable)
return 0;
+ drm_for_each_plane_mask(p, crtc->dev, crtc->state->plane_mask) {
+ if (plane->base.id == p->base.id)
+ continue;
+
+ if (p->state->zpos == state->zpos) {
+ DBG("zpos must be unique (zpos: %u)", state->zpos);
+ return -EINVAL;
+ }
+ }
+
if (state->crtc_x < 0 || state->crtc_y < 0)
return -EINVAL;
@@ -196,8 +208,7 @@ static void omap_plane_reset(struct drm_plane *plane)
* Set the zpos default depending on whether we are a primary or overlay
* plane.
*/
- plane->state->zpos = plane->type == DRM_PLANE_TYPE_PRIMARY
- ? 0 : omap_plane->id;
+ plane->state->zpos = omap_plane->idx;
}
static int omap_plane_atomic_set_property(struct drm_plane *plane,
@@ -284,6 +295,7 @@ struct drm_plane *omap_plane_init(struct drm_device *dev,
for (nformats = 0; formats[nformats]; ++nformats)
;
omap_plane->id = id;
+ omap_plane->idx = idx;
omap_plane->name = plane_id_to_name[id];
plane = &omap_plane->base;
@@ -297,7 +309,7 @@ struct drm_plane *omap_plane_init(struct drm_device *dev,
drm_plane_helper_add(plane, &omap_plane_helper_funcs);
omap_plane_install_properties(plane, &plane->base);
- drm_plane_create_zpos_property(plane, 0, 0, num_planes - 1);
+ drm_plane_create_zpos_property(plane, idx, 0, num_planes - 1);
return plane;
--
Peter
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: [Intel-gfx] [PATCH v2] drm/i915: Try EDID bitbanging on HDMI after failed read
On Wednesday, January 3, 2018 8:14:47 AM CET Jani Nikula wrote:
> On Tue, 02 Jan 2018, Chris Wilson wrote:
> > Quoting Rodrigo Vivi (2018-01-02 19:12:18)
> >
> >> On Sun, Dec 31, 2017 at 10:34:54PM +, Stefan Brüns wrote:
> >> > + edid = drm_get_edid(connector, i2c);
> >> > +
> >> > + if (!edid && !intel_gmbus_is_forced_bit(i2c)) {
> >> > + DRM_DEBUG_KMS("HDMI GMBUS EDID read failed, retry using
> >> > GPIO bit-banging\n"); + intel_gmbus_force_bit(i2c, true);
> >> > + edid = drm_get_edid(connector, i2c);
> >> > + intel_gmbus_force_bit(i2c, false);
> >> > + }
> >>
> >> Approach seems fine for this case.
> >> I just wonder what would be the risks of forcing this bit and edid read
> >> when nothing is present on the other end?>
> > Should be no more risky than using GMBUS as the bit-banging is the
> > underlying HW protocol; it should just be adding an extra delay to
> > the disconnected probe. Offset against the chance that it fixes
> > detection of borderline devices.
> >
> > I would say that given the explanation above, the question is why not
> > apply it universally? (Bonus points for including the explanation as
> > comments.)
>
> I'm wondering, is gmbus too fast for the adapters, does gmbus generally
> have different timing for the ack/nak as described in the commit message
> than bit banging, or are the adapters just plain buggy? Do we have any
> control over gmbus timings (don't have the time to peruse the bpsec just
> now)?
I have seen two different behaviours, one on the ~2009 GM965, the other on the
~2013 Haswell. The Haswell provides a 250..500ns hold time, the other does
not.
There is a flag in the GMBUS0 register, GMBUS_HOLD_EXT, "300ns hold time, rsvd
on Pineview". The driver does not set this flag. Possibly it is always set/
implied on the Haswell (which is post-Pineview), and should be set for
anything older than Pineview.
There is another odd fact with the GM965, according to the register setting it
should run at 100 kBit/s, but it only runs at 30 kBit/s. The Haswell runs at
100 kBit/s, as specified. As there are also idle periods ever 8 bytes, the
EDID read takes 270ms before it fails.
The bitbanging code, running at 45 kBit/s (2 * 20us per clock cycle plus
overhead) on the other hand just needs 58 ms, but keeps one core busy
(udelay).
Unfortunately I currently have no older system than the Haswell available, so
I can not check if the GMBUS_HOLD_EXT flag has any effect.
Kind regards,
Stefan
--
Stefan Brüns / Bergstraße 21 / 52062 Aachen
home: +49 241 53809034 mobile: +49 151 50412019
signature.asc
Description: This is a digitally signed message part.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 104001] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, last signaled seq=6582, last emitted seq=6584
https://bugs.freedesktop.org/show_bug.cgi?id=104001 mikhail.v.gavri...@gmail.com changed: What|Removed |Added Summary|GPU driver hung when start |[drm:amdgpu_job_timedout |steam client while playback |[amdgpu]] *ERROR* ring gfx |video on Youtube (it occurs |timeout, last signaled |on latest staging kernel) |seq=6582, last emitted ||seq=6584 -- 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 104001] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, last signaled seq=6582, last emitted seq=6584
https://bugs.freedesktop.org/show_bug.cgi?id=104001 --- Comment #9 from mikhail.v.gavri...@gmail.com --- Created attachment 136517 --> https://bugs.freedesktop.org/attachment.cgi?id=136517&action=edit dmesg with 4.15.0-rc2 amd-staging-drm-next -- 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 104001] GPU driver hung when start steam client while playback video on Youtube (it occurs on latest staging kernel)
https://bugs.freedesktop.org/show_bug.cgi?id=104001 Christian König changed: What|Removed |Added Summary|[drm:amdgpu_job_timedout|GPU driver hung when start |[amdgpu]] *ERROR* ring gfx |steam client while playback |timeout, last signaled |video on Youtube (it occurs |seq=6582, last emitted |on latest staging kernel) |seq=6584| -- 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 104001] GPU driver hung when start steam client while playback video on Youtube (it occurs on latest staging kernel)
https://bugs.freedesktop.org/show_bug.cgi?id=104001 --- Comment #10 from Christian König --- Yeah, I enabled more error messages on amd-staging-drm-next. But please don't change the bug subject to something less descriptive. -- 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: [drm_hwcomposer PATCH] Take Connection state into account. (v2)
Hey Mauro,
Thanks for the patch! It builds and looks good to me, but I have some
suggestions however.
On Wed, 2018-01-03 at 11:10 +0100, Mauro Rossi wrote:
> These changes avoid following logcat error on integrated and
> dedicated GPUs:
>
> ... 2245 2245 E hwc-drm-resources: Could not find a suitable
> encoder/crtc for display 2
> ... 2245 2245 E hwc-drm-resources: Failed CreateDisplayPipe 56 with
> -19
> ... 2245 2245 E hwcomposer-drm: Can't initialize Drm object -19
It isn't quite clear clear which errors belong to which changes,
to make this patch a bit more bisectable it would be nice to see
independent commits created for each error.
>
> (v1) There are various places where we should be really taking
> connection
> state into account before querying the properties or assuming it
> as primary. This patch fixes them.
>
> BUG=None.
> TEST=System boots up and shows UI.
>
> (v1) Signed-off-by: Jim Bish
>
> (v2) porting of original commit 76fb87e675 of android-ia master
> with additional external connector types (DisplayPort, DVID, DVII,
> VGA)
> Tested with i965 on Sandybridge and nouveau on GT120, GT610
The commit message isn't really following the usual format. It doesn't
need to include a changelog (that is typically placed between the "---"
markers in the email instead),
and it is missing a signoff from the submitter (you).
The BUG and TEST fields are not strictly required either, but aren't a
problem.
> ---
> drmconnector.cpp | 4 +++-
> drmresources.cpp | 9 +++--
> 2 files changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/drmconnector.cpp b/drmconnector.cpp
> index 247f56b..145518f 100644
> --- a/drmconnector.cpp
> +++ b/drmconnector.cpp
> @@ -73,7 +73,9 @@ bool DrmConnector::internal() const {
> }
>
> bool DrmConnector::external() const {
> - return type_ == DRM_MODE_CONNECTOR_HDMIA;
> + return type_ == DRM_MODE_CONNECTOR_HDMIA || type_ ==
> DRM_MODE_CONNECTOR_DisplayPort ||
> + type_ == DRM_MODE_CONNECTOR_DVID || type_ ==
> DRM_MODE_CONNECTOR_DVII ||
> + type_ == DRM_MODE_CONNECTOR_VGA;
> }
The changes to external() should probably be broken out into it's own
commit, since external() is called elsewhere changes to it _could_
introduce issues.
>
> bool DrmConnector::valid_type() const {
> diff --git a/drmresources.cpp b/drmresources.cpp
> index 32dd376..d582cfe 100644
> --- a/drmresources.cpp
> +++ b/drmresources.cpp
> @@ -159,7 +159,7 @@ int DrmResources::Init() {
>
>// First look for primary amongst internal connectors
>for (auto &conn : connectors_) {
> -if (conn->internal() && !found_primary) {
> +if (conn->state() == DRM_MODE_CONNECTED && conn->internal() &&
> !found_primary) {
>conn->set_display(0);
>found_primary = true;
> } else {
> @@ -170,7 +170,7 @@ int DrmResources::Init() {
>
>// Then look for primary amongst external connectors
>for (auto &conn : connectors_) {
> -if (conn->external() && !found_primary) {
> +if (conn->state() == DRM_MODE_CONNECTED && conn->external() &&
> !found_primary) {
>conn->set_display(0);
>found_primary = true;
> }
> @@ -288,6 +288,11 @@ int DrmResources::TryEncoderForDisplay(int
> display, DrmEncoder *enc) {
>
> int DrmResources::CreateDisplayPipe(DrmConnector *connector) {
>int display = connector->display();
> +
> + // skip not connected
> + if (connector->state() == DRM_MODE_DISCONNECTED)
> +return 0;
> +
>/* Try to use current setup first */
>if (connector->encoder()) {
> int ret = TryEncoderForDisplay(display, connector->encoder());
signature.asc
Description: This is a digitally signed message part
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V4 22/26] video: fbdev: intelfb: deprecate pci_get_bus_and_slot()
On Tuesday, January 02, 2018 08:38:24 AM Sinan Kaya wrote: > On 12/19/2017 12:37 AM, Sinan Kaya wrote: > > pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as > > where a PCI device is present. This restricts the device drivers to be > > reused for other domain numbers. > > > > Getting ready to remove pci_get_bus_and_slot() function in favor of > > pci_get_domain_bus_and_slot(). > > > > Find the domain number from pdev. > > > > Signed-off-by: Sinan Kaya > > Any feedback here ? most of the remaining patches have the ACK except these. Acked-by: Bartlomiej Zolnierkiewicz Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V4 23/26] video: fbdev: nvidia: deprecate pci_get_bus_and_slot()
On Tuesday, January 02, 2018 08:38:03 AM Sinan Kaya wrote: > On 12/19/2017 12:37 AM, Sinan Kaya wrote: > > pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as > > where a PCI device is present. This restricts the device drivers to be > > reused for other domain numbers. > > > > Getting ready to remove pci_get_bus_and_slot() function in favor of > > pci_get_domain_bus_and_slot(). > > > > struct nvidia_par has a pointer to struct pci_dev. Use the pci_dev > > member to extract the domain information and pass it to > > pci_get_domain_bus_and_slot() function. > > > > Signed-off-by: Sinan Kaya > > Any feedback here ? most of the remaining patches have the ACK except these. Acked-by: Bartlomiej Zolnierkiewicz Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V4 24/26] video: fbdev: riva: deprecate pci_get_bus_and_slot()
On Tuesday, January 02, 2018 08:37:32 AM Sinan Kaya wrote: > On 12/19/2017 12:38 AM, Sinan Kaya wrote: > > pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as > > where a PCI device is present. This restricts the device drivers to be > > reused for other domain numbers. > > > > Getting ready to remove pci_get_bus_and_slot() function in favor of > > pci_get_domain_bus_and_slot(). > > > > struct riva_par has a pointer to struct pci_dev. Use the pci_dev member > > to extract the domain information. > > > > Change the function signature for CalcStateExt and RivaGetConfig to pass > > in struct pci_dev in addition to RIVA_HW_INST so that code inside the > > riva_hw.c can also calculate domain number and pass it to > > pci_get_domain_bus_and_slot(). > > > > Signed-off-by: Sinan Kaya > > Any feedback here, most of the remaining patches have the ACK except these? Acked-by: Bartlomiej Zolnierkiewicz Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC 1/3] drm/msm/mdp5: Add global state as a private atomic object
On 12/21/2017 03:26 PM, Daniel Vetter wrote:
On Thu, Dec 21, 2017 at 11:44:23AM +0530, Archit Taneja wrote:
Global shared resources (hwpipes, hwmixers and SMP) for MDP5 are
implemented as a part of atomic state by subclassing drm_atomic_state.
The preferred approach is to use the drm_private_obj infrastructure
available in the atomic core.
mdp5_global_state is introduced as a drm atomic private object. The two
funcs mdp5_get_global_state() and mdp5_get_existing_global_state() are
the two variants that will be used to access mdp5_global_state.
This will replace the existing mdp5_state struct (which subclasses
drm_atomic_state) and the funcs around it. These will be removed later
once we mdp5_global_state is put to use everywhere.
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c | 86 +
drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h | 27 +++
2 files changed, 113 insertions(+)
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
index f7c0698fec40..dfc4d81124d5 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
@@ -106,6 +106,86 @@ static void mdp5_swap_state(struct msm_kms *kms, struct
drm_atomic_state *state)
swap(to_kms_state(state)->state, mdp5_kms->state);
}
+/* Global/shared object state funcs */
+
+/*
+ * This is a helper that returns the private state currently in operation.
+ * Note that this would return the "old_state" if called in the atomic check
+ * path, and the "new_state" after the atomic swap has been done.
+ */
+struct mdp5_global_state *
+mdp5_get_existing_global_state(struct mdp5_kms *mdp5_kms)
+{
+ return to_mdp5_global_state(mdp5_kms->glob_base.state);
This doesn't match the existing state stuff for everything else. Here you
look at the global state, but not at the one hanging off drm_atomic_state.
Maybe we should add a drm_atomic_get_existing_private_obj_state function
to make this easier?
I'm also not 100% sure on what semantics you want precisely.
I just wanted a func that returns me the private obj's state that is currently
"in use". I.e, the old state pre-swap, and the new state post-swap. If I use
drm_atomic_get_private_obj_state() after the swap has occurred, I get the old
state back. In other words, there aren't funcs for private objs like
drm_atomic_get_new_crtc_state() and drm_atomic_get_old_crtc_state() that we
can use. I'll go through the code again carefully to see if my understanding
isn't screwed up.
+}
+
+/*
+ * This acquires the modeset lock set aside for global state, creates
+ * a new duplicated private object state.
+ */
+struct mdp5_global_state *mdp5_get_global_state(struct drm_atomic_state *s)
+{
+ struct msm_drm_private *priv = s->dev->dev_private;
+ struct mdp5_kms *mdp5_kms = to_mdp5_kms(to_mdp_kms(priv->kms));
+ struct drm_private_state *priv_state;
+ int ret;
+
+ ret = drm_modeset_lock(&mdp5_kms->glob_state_lock, s->acquire_ctx);
+ if (ret)
+ return ERR_PTR(ret);
+
+ priv_state = drm_atomic_get_private_obj_state(s, &mdp5_kms->glob_base);
+ if (IS_ERR(priv_state))
+ return ERR_CAST(priv_state);
+
+ return to_mdp5_global_state(priv_state);
+}
+
+static struct drm_private_state *
+mdp5_global_duplicate_state(struct drm_private_obj *obj)
+{
+ struct mdp5_global_state *state;
+
+ state = kmemdup(obj->state, sizeof(*state), GFP_KERNEL);
+ if (!state)
+ return NULL;
+
+ __drm_atomic_helper_private_obj_duplicate_state(obj, &state->base);
+
+ return &state->base;
+}
+
+static void mdp5_global_destroy_state(struct drm_private_obj *obj,
+ struct drm_private_state *state)
+{
+ struct mdp5_global_state *mdp5_state = to_mdp5_global_state(state);
+
+ kfree(mdp5_state);
+}
+
+static const struct drm_private_state_funcs mdp5_global_state_funcs = {
+ .atomic_duplicate_state = mdp5_global_duplicate_state,
+ .atomic_destroy_state = mdp5_global_destroy_state,
+};
+
+static int mdp5_global_obj_init(struct mdp5_kms *mdp5_kms)
+{
+ struct mdp5_global_state *state;
+
+ state = kzalloc(sizeof(*state), GFP_KERNEL);
+ if (!state)
+ return -ENOMEM;
+
+ drm_modeset_lock_init(&mdp5_kms->glob_state_lock);
I thought a bit the last few days about how to integrate modeset locking
into driver private state objects. I think the simplest solution would be
if we just add a drm_modeset_lock to drm_private_obj, and push the locking
(both here and in the mst helper) into the core private obj code.
I'm also a bit unclear on how many private objs one should create. In this
patchset,
I just create one private obj instance, and stuff all of our shared resources
into
it (see mdp5_global_state below). I didn't see the point in creating one priv
object
per shared resource, since a single
[Bug 101483] A10-8780P (Carrizo) + R7 M260/M265 does not boot without any "workaround" parameter.
https://bugs.freedesktop.org/show_bug.cgi?id=101483 FFAB changed: What|Removed |Added Attachment #136158|0 |1 is obsolete|| Attachment #136159|0 |1 is obsolete|| --- Comment #37 from FFAB --- Created attachment 136521 --> https://bugs.freedesktop.org/attachment.cgi?id=136521&action=edit 2018_01_02_dmesg_4.15-rc6.txt, booting without additional kernel parameter -- 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 101483] A10-8780P (Carrizo) + R7 M260/M265 does not boot without any "workaround" parameter.
https://bugs.freedesktop.org/show_bug.cgi?id=101483 --- Comment #38 from FFAB --- Created attachment 136522 --> https://bugs.freedesktop.org/attachment.cgi?id=136522&action=edit 2018_01_02_dmesg_4.15-rc6_iommu_soft.txt, booting with kernel parameter iommu=soft -- 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 101483] A10-8780P (Carrizo) + R7 M260/M265 does not boot without any "workaround" parameter.
https://bugs.freedesktop.org/show_bug.cgi?id=101483 --- Comment #39 from FFAB --- Upstream kernel test - kernel 4.15-rc6 Installation, on which upstream kernel was installed: ubuntu 16.04.3, kernel 4.10.0-42, updated 2018-01-02 1. booting without any workaround parameters 2. booting with kernel parameter iommu=soft boot-time 45sec ->> Login-screen!!! Local login Now: led backlight brightness adjustable hdmi connection works systemsettings - display and monitor adjustable "sudo lshw -short", missing line: /0/100/3.1/0 display Topaz XT [Radeon R7 M260/M265] attachments: 2018_01_02_dmesg_4.15-rc6.txt, 2018_01_02_dmesg_4.15-rc6_iommu_soft.txt -- 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/3] update compatible string for ILI9225
Den 21.12.2017 19.33, skrev David Lechner: This updates the device tree compatible string for an ILI9225 display. Detailed explanation is in the patches. David Lechner (3): dt-bindings: Add "vot" vendor prefix dt-bindings: update compatible string for ILI9225 drm/tinydrm: Update ILI9225 compatible string Series applied to drm-misc. Noralf. Documentation/devicetree/bindings/display/ilitek,ili9225.txt | 4 ++-- Documentation/devicetree/bindings/vendor-prefixes.txt| 1 + drivers/gpu/drm/tinydrm/ili9225.c| 4 ++-- 3 files changed, 5 insertions(+), 4 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 3/3] drm/tinydrm: add driver for ST7735R panels
Den 02.01.2018 10.42, skrev Linus Walleij: On Mon, Jan 1, 2018 at 8:02 PM, David Lechner wrote: This adds a new driver for Sitronix ST7735R display panels. This has been tested using an Adafruit 1.8" TFT. Signed-off-by: David Lechner Reviewed-by: Noralf Trønnes Reviewed-by: Linus Walleij Thanks, series applied to drm-misc. Noralf. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3] Fix loading of module radeonfb on PowerMac
On Thursday, December 21, 2017 11:07:56 PM Mathieu Malaterre wrote:
> When the linux kernel is build with (typical kernel ship with Debian
> installer):
>
> CONFIG_FB_OF=y
> CONFIG_VT_HW_CONSOLE_BINDING=y
> CONFIG_FB_RADEON=m
>
> The offb driver takes precedence over module radeonfb. It is then
> impossible to load the module, error reported is:
>
> [ 96.551486] radeonfb :00:10.0: enabling device (0006 -> 0007)
> [ 96.551526] radeonfb :00:10.0: BAR 0: can't reserve [mem
> 0x9800-0x9fff pref]
> [ 96.551531] radeonfb (:00:10.0): cannot request region 0.
> [ 96.551545] radeonfb: probe of :00:10.0 failed with error -16
>
> This patch reproduce the behavior of the module radeon, so as to make it
> possible to load radeonfb when offb is first loaded.
>
> It should be noticed that `offb_destroy` is never called which explain the
> need to skip error detection on the radeon side.
This still needs to be explained more, from my last mail:
"The last put_fb_info() on fb_info should call ->fb_destroy
(offb_destroy in our case) and remove_conflicting_framebuffers()
is calling put_fb_info() so there is some extra reference on
fb_info somewhere preventing it from going away.
Please look into fixing this."
> Signed-off-by: Mathieu Malaterre
> Link: https://bugs.debian.org/826629#57
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=119741
> Suggested-by: Lennart Sorensen
> ---
> v2: Only fails when CONFIG_PCC is not set
> v3: Only fails when CONFIG_FB_OF is not set, CONFIG_PCC was too broad. Since
> the conflicts in region is due to OFfb explicitly refers to it.
It seems that there may still be configurations when this is
incorrect -> when offb drives primary (non-radeon) card and radeonfb
drives secondary (radeon) card..
> drivers/video/fbdev/aty/radeon_base.c | 26 ++
> 1 file changed, 26 insertions(+)
>
> diff --git a/drivers/video/fbdev/aty/radeon_base.c
> b/drivers/video/fbdev/aty/radeon_base.c
> index 4d77daeecf99..221879196531 100644
> --- a/drivers/video/fbdev/aty/radeon_base.c
> +++ b/drivers/video/fbdev/aty/radeon_base.c
> @@ -2259,6 +2259,22 @@ static const struct bin_attribute edid2_attr = {
> .read = radeon_show_edid2,
> };
>
> +static int radeon_kick_out_firmware_fb(struct pci_dev *pdev)
> +{
> + struct apertures_struct *ap;
> +
> + ap = alloc_apertures(1);
> + if (!ap)
> + return -ENOMEM;
> +
> + ap->ranges[0].base = pci_resource_start(pdev, 0);
> + ap->ranges[0].size = pci_resource_len(pdev, 0);
> +
> + remove_conflicting_framebuffers(ap, KBUILD_MODNAME, false);
> + kfree(ap);
> +
> + return 0;
> +}
>
> static int radeonfb_pci_register(struct pci_dev *pdev,
>const struct pci_device_id *ent)
> @@ -2312,19 +2328,27 @@ static int radeonfb_pci_register(struct pci_dev *pdev,
> rinfo->fb_base_phys = pci_resource_start (pdev, 0);
> rinfo->mmio_base_phys = pci_resource_start (pdev, 2);
>
> + ret = radeon_kick_out_firmware_fb(pdev);
> + if (ret)
> + return ret;
> +
> /* request the mem regions */
> ret = pci_request_region(pdev, 0, "radeonfb framebuffer");
> if (ret < 0) {
> +#ifndef CONFIG_FB_OF
> printk( KERN_ERR "radeonfb (%s): cannot request region 0.\n",
> pci_name(rinfo->pdev));
> goto err_release_fb;
> +#endif
> }
>
> ret = pci_request_region(pdev, 2, "radeonfb mmio");
> if (ret < 0) {
> +#ifndef CONFIG_FB_OF
> printk( KERN_ERR "radeonfb (%s): cannot request region 2.\n",
> pci_name(rinfo->pdev));
> goto err_release_pci0;
> +#endif
> }
>
> /* map the regions */
> @@ -2509,10 +2533,12 @@ static int radeonfb_pci_register(struct pci_dev *pdev,
> iounmap(rinfo->mmio_base);
> err_release_pci2:
> pci_release_region(pdev, 2);
> +#ifndef CONFIG_FB_OF
> err_release_pci0:
> pci_release_region(pdev, 0);
> err_release_fb:
> framebuffer_release(info);
> +#endif
> err_disable:
> err_out:
> return ret;
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Mesa-dev] Allocator Nouveau driver, Mesa EXT_external_objects, and DRM metadata import interfaces
On Thu, Dec 28, 2017 at 1:24 PM, Miguel Angel Vico wrote: > (Adding dri-devel back, and trying to respond to some comments from > the different forks) > > James Jones wrote: > >> Your worst case analysis above isn't far off from our HW, give or take >> some bits and axes here and there. We've started an internal discussion >> about how to lay out all the bits we need. It's hard to even enumerate >> them all without having a complete understanding of what capability sets >> are going to include, a fully-optimized implementation of the mechanism >> on our HW, and lot's of test scenarios though. > > (thanks James for most of the info below) > > To elaborate a bit, if we want to share an allocation across GPUs for 3D > rendering, it seems we would need 12 bits to express our > swizzling/tiling memory layouts for fermi+. In addition to that, > maxwell uses 3 more bits for this, and we need an extra bit to identify > pre-fermi representations. > > We also need one bit to differentiate between Tegra and desktop, and > another one to indicate whether the layout is otherwise linear. > > Then things like whether compression is used (one more bit), and we can > probably get by with 3 bits for the type of compression if we are > creative. However, it'd be way easier to just track arch + page kind, > which would be like 32 bits on its own. > > Whether Z-culling and/or zero-bandwidth-clears are used may be another 3 > bits. > > If device-local properties are included, we might need a couple more > bits for caching. > > We may also need to express locality information, which may take at > least another 2 or 3 bits. > > If we want to share array textures too, you also need to pass the array > pitch. Is it supposed to be encoded in a modifier too? That's 64 bits on > its own. > > So yes, as James mentioned, with some effort, we could technically fit > our current allocation parameters in a modifier, but I'm still not > convinced this is as future proof as it could be as our hardware grows > in capabilities. > > > Daniel Stone wrote: > >> So I reflexively >> get a bit itchy when I see the kernel being used to transit magic >> blobs of data which are supplied by userspace, and only interpreted by >> different userspace. Having tiling formats hidden away means that >> we've had real-world bugs in AMD hardware, where we end up displaying >> garbage because we cannot generically reason about the buffer >> attributes. > > I'm a bit confused. Can't modifiers be specified by vendors and only > interpreted by drivers? My understanding was that modifiers could > actually be treated as opaque 64-bit data, in which case they would > qualify as "magic blobs of data". Otherwise, it seems this wouldn't be > scalable. What am I missing? > > > Daniel Vetter wrote: > >> I think in the interim figuring out how to expose kms capabilities >> better (and necessarily standardizing at least some of them which >> matter at the compositor level, like size limits of framebuffers) >> feels like the place to push the ecosystem forward. In some way >> Miguel's proposal looks a bit backwards, since it adds the pitch >> capabilities to addfb, but at addfb time you've allocated everything >> already, so way too late to fix things up. With modifiers we've added >> a very simple per-plane property to list which modifiers can be >> combined with which pixel formats. Tiny start, but obviously very far >> from all that we'll need. > > Not sure whether I might be misunderstanding your statement, but one of > the allocator main features is negotiation of nearly optimal allocation > parameters given a set of uses on different devices/engines by the > capability merge operation. A client should have queried what every > device/engine is capable of for the given uses, find the optimal set of > capabilities, and use it for allocating a buffer. At the moment these > parameters are given to KMS, they are expected to be good. If they > aren't, the client didn't do things right. > > > Rob Clark wrote: > >> It does seem like, if possible, starting out with modifiers for now at >> the kernel interface would make life easier, vs trying to reinvent >> both kernel and userspace APIs at the same time. Userspace APIs are >> easier to change or throw away. Presumably by the time we get to the >> point of changing kernel uabi, we are already using, and pretty happy >> with, serialized liballoc data over the wire in userspace so it is >> only a matter of changing the kernel interface. > > I guess we can indeed start with modifiers for now, if that's what it > takes to get the allocator mechanisms rolling. However, it seems to me > that we won't be able to encode the same type of information included > in capability sets with modifiers in all cases. For instance, if we end > up encoding usage transition information in capability sets, how that > would translate to modifiers? > > I assume display doesn't really care about a lot of the data capability > sets may encode, but is
Re: [amd-staging-drm-next] regression - *ERROR* Don't have enable_spread_spectrum_on_ppll for v4
On 2017-12-27 04:04 AM, Michel Dänzer wrote:
> On 2017-12-27 05:43 AM, Dieter Nützel wrote:
>> Hello AMD team,
>>
>> I got this since latest 'amd-staging-drm-next' git update
>> (#b956c586e58a) during boot with Polaris RX580 DC on:
>>
>> [ 3.586342] [drm:dal_bios_parser_init_cmd_tbl [amdgpu]] *ERROR* Don't
>> have enable_spread_spectrum_on_ppll for v4
>> [ 3.586410] [drm:dal_bios_parser_init_cmd_tbl [amdgpu]] *ERROR* Don't
>> have program_clock for v7
>>
>> Latest GOOD commit was #b341a19e8039 (drm/radeon: Remove
>> KFD_CIK_SDMA_QUEUE_OFFSET).
>>
>> I'll bisect if I have some time.
>> Maybe someone send a hint to the right commit.
>
> I don't think bisecting is useful, it'll most likely just identify
> commit 040dda2e1f52 ("drm/amd/display: Error print when ATOM BIOS
> implementation is missing") which started printing these messages for
> missing ATOM BIOS implementations.
>
> I'm not sure, but I suspect these messages are harmless, given that
> things are otherwise presumably still working as well as they were before.
These are harmless. I wrongfully assumed that printing errors here should be
fine on all ASICs as I assumed all relevant functions were implemented.
Apparently they're not, proving me wrong and proving the usefulness of some
sort of print here. I'll send a patch to demote the prints to debug level.
Harry
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 00/13] remove_conflicting_framebuffers() cleanup
On Monday, November 27, 2017 11:30:44 AM Daniel Vetter wrote: > On Fri, Nov 24, 2017 at 06:53:25PM +0100, Michał Mirosław wrote: > > This series cleans up duplicated code for replacing firmware FB > > driver with proper DRI driver and adds handover support to > > Tegra driver. Please Cc: me on and linux-fbdev ML on fbdev related patches (I was Cc:-ed only on the cover letter and patch #10, linux-fbdev was not Cc:-ed at all). > > The last patch is here because it uses new semantics of > > remove_conflicting_framebuffers() from this series. This > > can be considered independently, though. > > Except for that patches I've commented on: > > Acked-by: Daniel Vetter > > Since this is for tegra and Thierry has drm-misc commit rights, it's > probably simplest when Thierry pushes this all to drm-misc once driver > maintainers had a chance to look at it. Also needs and ack from Bart for > the fbdev sides. For fbdev changes: Acked-by: Bartlomiej Zolnierkiewicz Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4.15] drm/amd/display: call set csc_default if enable adjustment is false
On 2017-12-31 10:17 AM, Alex Deucher wrote:
> On Fri, Dec 29, 2017 at 6:11 AM, Daniel Drake wrote:
>> From: Yue Hin Lau
>>
>> Signed-off-by: Yue Hin Lau
>> Reviewed-by: Eric Bernstein
>> Acked-by: Harry Wentland
>> Signed-off-by: Alex Deucher
>> [dr...@endlessm.com: backport to 4.15]
>> Signed-off-by: Daniel Drake
>> ---
>> drivers/gpu/drm/amd/display/dc/dcn10/dcn10_dpp.h | 2 +-
>> drivers/gpu/drm/amd/display/dc/dcn10/dcn10_dpp_cm.c | 6 ++
>> drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c | 2 ++
>> drivers/gpu/drm/amd/display/dc/inc/hw/dpp.h | 2 +-
>> 4 files changed, 6 insertions(+), 6 deletions(-)
>>
>> Testing Acer Aspire TC-380 engineering sample (Raven Ridge), the display
>> comes up with an excessively green tint. This patch (from
>> amd-staging-drm-next)
>> solves the issue. Can it be included in Linux 4.15?
>
> Looks ok to me. Unless Harry or Leo have any objections, I'll add it
> to my queue.
>
No objections. Thanks, Daniel.
Harry
> Thanks!
>
> Alex
>
>
>>
>> diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_dpp.h
>> b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_dpp.h
>> index a9782b1aba47..34daf895f848 100644
>> --- a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_dpp.h
>> +++ b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_dpp.h
>> @@ -1360,7 +1360,7 @@ void dpp1_cm_set_output_csc_adjustment(
>>
>> void dpp1_cm_set_output_csc_default(
>> struct dpp *dpp_base,
>> - const struct default_adjustment *default_adjust);
>> + enum dc_color_space colorspace);
>>
>> void dpp1_cm_set_gamut_remap(
>> struct dpp *dpp,
>> diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_dpp_cm.c
>> b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_dpp_cm.c
>> index 40627c244bf5..ed1216b53465 100644
>> --- a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_dpp_cm.c
>> +++ b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_dpp_cm.c
>> @@ -225,14 +225,13 @@ void dpp1_cm_set_gamut_remap(
>>
>> void dpp1_cm_set_output_csc_default(
>> struct dpp *dpp_base,
>> - const struct default_adjustment *default_adjust)
>> + enum dc_color_space colorspace)
>> {
>>
>> struct dcn10_dpp *dpp = TO_DCN10_DPP(dpp_base);
>> uint32_t ocsc_mode = 0;
>>
>> - if (default_adjust != NULL) {
>> - switch (default_adjust->out_color_space) {
>> + switch (colorspace) {
>> case COLOR_SPACE_SRGB:
>> case COLOR_SPACE_2020_RGB_FULLRANGE:
>> ocsc_mode = 0;
>> @@ -253,7 +252,6 @@ void dpp1_cm_set_output_csc_default(
>> case COLOR_SPACE_UNKNOWN:
>> default:
>> break;
>> - }
>> }
>>
>> REG_SET(CM_OCSC_CONTROL, 0, CM_OCSC_MODE, ocsc_mode);
>> diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
>> b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
>> index 961ad5c3b454..05dc01e54531 100644
>> --- a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
>> +++ b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
>> @@ -2097,6 +2097,8 @@ static void program_csc_matrix(struct pipe_ctx
>> *pipe_ctx,
>> tbl_entry.color_space = color_space;
>> //tbl_entry.regval = matrix;
>>
>> pipe_ctx->plane_res.dpp->funcs->opp_set_csc_adjustment(pipe_ctx->plane_res.dpp,
>> &tbl_entry);
>> + } else {
>> +
>> pipe_ctx->plane_res.dpp->funcs->opp_set_csc_default(pipe_ctx->plane_res.dpp,
>> colorspace);
>> }
>> }
>> static bool is_lower_pipe_tree_visible(struct pipe_ctx *pipe_ctx)
>> diff --git a/drivers/gpu/drm/amd/display/dc/inc/hw/dpp.h
>> b/drivers/gpu/drm/amd/display/dc/inc/hw/dpp.h
>> index 83a68460edcd..9420dfb94d39 100644
>> --- a/drivers/gpu/drm/amd/display/dc/inc/hw/dpp.h
>> +++ b/drivers/gpu/drm/amd/display/dc/inc/hw/dpp.h
>> @@ -64,7 +64,7 @@ struct dpp_funcs {
>>
>> void (*opp_set_csc_default)(
>> struct dpp *dpp,
>> - const struct default_adjustment *default_adjust);
>> + enum dc_color_space colorspace);
>>
>> void (*opp_set_csc_adjustment)(
>> struct dpp *dpp,
>> --
>> 2.14.1
>>
>> ___
>> amd-gfx mailing list
>> amd-...@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [-next PATCH 2/4] treewide: Use DEVICE_ATTR_RW
On Tuesday, December 19, 2017 10:15:07 AM Joe Perches wrote:
> Convert DEVICE_ATTR uses to DEVICE_ATTR_RW where possible.
>
> Done with perl script:
>
> $ git grep -w --name-only DEVICE_ATTR | \
> xargs perl -i -e 'local $/; while (<>) {
> s/\bDEVICE_ATTR\s*\(\s*(\w+)\s*,\s*\(?(\s*S_IRUGO\s*\|\s*S_IWUSR|\s*S_IWUSR\s*\|\s*S_IRUGO\s*|\s*0644\s*)\)?\s*,\s*\1_show\s*,\s*\1_store\s*\)/DEVICE_ATTR_RW(\1)/g;
> print;}'
>
> Signed-off-by: Joe Perches
> ---
> arch/s390/kernel/topology.c | 3 +--
> arch/tile/kernel/sysfs.c | 2 +-
> drivers/gpu/drm/i915/i915_sysfs.c| 6 ++---
> drivers/platform/x86/compal-laptop.c | 18 +--
> drivers/s390/cio/device.c| 2 +-
> drivers/scsi/lpfc/lpfc_attr.c| 43
>
> drivers/thermal/thermal_sysfs.c | 9
> drivers/tty/serial/sh-sci.c | 2 +-
> drivers/usb/host/xhci-dbgcap.c | 2 +-
> drivers/usb/phy/phy-tahvo.c | 2 +-
> drivers/video/fbdev/auo_k190x.c | 4 ++--
> drivers/video/fbdev/w100fb.c | 4 ++--
> lib/test_firmware.c | 14 +---
> lib/test_kmod.c | 14 +---
> sound/soc/omap/mcbsp.c | 4 ++--
> 15 files changed, 49 insertions(+), 80 deletions(-)
For fbdev changes:
Acked-by: Bartlomiej Zolnierkiewicz
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [drm_hwcomposer PATCH] Take Connection state into account. (v2)
Hey Mauro,
On Wed, 2018-01-03 at 13:40 +0100, Mauro Rossi wrote:
>
>
> 2018-01-03 12:16 GMT+01:00 Robert Foss :
> > Hey Mauro,
> > /
> > Thanks for the patch! It builds and looks good to me, but I have
> > some
> > suggestions however.
> >
> >
> > On Wed, 2018-01-03 at 11:10 +0100, Mauro Rossi wrote:
> > > These changes avoid following logcat error on integrated and
> > > dedicated GPUs:
> > >
> > > ... 2245 2245 E hwc-drm-resources: Could not find a suitable
> > > encoder/crtc for display 2
> > > ... 2245 2245 E hwc-drm-resources: Failed CreateDisplayPipe 56
> > with
> > > -19
> > > ... 2245 2245 E hwcomposer-drm: Can't initialize Drm object -19
> >
> > It isn't quite clear clear which errors belong to which changes,
> > to make this patch a bit more bisectable it would be nice to see
> > independent commits created for each error.
>
> Hi Robert,
>
> In this case I honestly do not think that splitting would add too
> much value,
> original commit (v1) is well documented in [1] and tackles with bug
> in drmresources.cpp
> which currently fails to find workable crtc -> encoder -> display
> output combination
> for integrated and dedicated GPUs. Besides that it was also adding
> DisplayPort drm mode connector type
>
> So changes in drmresources.cpp belong to solving "Could not find a
> suitable encoder/crtc for display X" problem,
> which is a show stopper for enabling mainline graphics in android-x86
>
> Other developers observed independently that the current
> implementation is "embedded oriented" and only checks the first
> display output,
> isn't it?
As far as I remember it prioritizes the internal connections, if none
are found, it will use the external ones.
>
> The only change I did in drmconnector.cpp is to account for the
> additional external drm mode connectors types
> which were missing (DVID, DVII, VGA) . One question on my side: Do we
> need more?
I think they can be added as need be, that's been the process this far.
>
> Besides these minor types lists discussions, I would propose you to
> check with Jim Bish if he should have the credit for the patch
> and review the coding of his changes.
So, I think we could just have both of you SOBs in the commit message,
and the would be fine.
>
>
> > >
> > > (v1) There are various places where we should be really taking
> > > connection
> > > state into account before querying the properties or assuming it
> > > as primary. This patch fixes them.
> > >
> > > BUG=None.
> > > TEST=System boots up and shows UI.
> > >
> > > (v1) Signed-off-by: Jim Bish
> > >
> > > (v2) porting of original commit 76fb87e675 of android-ia master
> > > with additional external connector types (DisplayPort, DVID,
> > DVII,
> > > VGA)
> > > Tested with i965 on Sandybridge and nouveau on GT120, GT610
> >
> > The commit message isn't really following the usual format. It
> > doesn't
> > need to include a changelog (that is typically placed between the
> > "---"
> > markers in the email instead),
> > and it is missing a signoff from the submitter (you).
>
> Sorry I don't have a signature, as usually my patches need sign-off
> from professionals,
> I'm a (crash test dummy) hobbyist..really :-)
>
> Maybe Rob Herring, Qiang Yu or Chih-Wei could review and sign-off
> the proposed patch
If you've tested or modified the code I would encourage you to add your
Signoff-by or Tested-by.
>
>
> > The BUG and TEST fields are not strictly required either, but
> > aren't a
> > problem.
>
> That part is the original Jim Bish commit message [1], my changes
> version is (v2)
> Sorry if I was not clear enought
That's quite alright. So let's clean up this commit message, and add
your Tested-by or Signoff-by (depending on if you changed any of the
code) and then I'll merge it.
Lastly, thanks for having a look at this, your contributions are very
welcome!
>
> > > ---
> > > drmconnector.cpp | 4 +++-
> > > drmresources.cpp | 9 +++--
> > > 2 files changed, 10 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drmconnector.cpp b/drmconnector.cpp
> > > index 247f56b..145518f 100644
> > > --- a/drmconnector.cpp
> > > +++ b/drmconnector.cpp
> > > @@ -73,7 +73,9 @@ bool DrmConnector::internal() const {
> > > }
> > >
> > > bool DrmConnector::external() const {
> > > - return type_ == DRM_MODE_CONNECTOR_HDMIA;
> > > + return type_ == DRM_MODE_CONNECTOR_HDMIA || type_ ==
> > > DRM_MODE_CONNECTOR_DisplayPort ||
> > > + type_ == DRM_MODE_CONNECTOR_DVID || type_ ==
> > > DRM_MODE_CONNECTOR_DVII ||
> > > + type_ == DRM_MODE_CONNECTOR_VGA;
> > > }
> >
> > The changes to external() should probably be broken out into it's
> > own
> > commit, since external() is called elsewhere changes to it _could_
> > introduce issues.
>
> Will you check the code, involving Jim Bish if necessary, about these
> potential issues?
> I am available to perform changes/tests, but the original maker will
> be better.
> Cheers
>
> Mauro
I won't, but it's ok the wa
Re: [PATCH v3 00/27] kill devm_ioremap_nocache
On Sun, Dec 24, 2017 at 9:55 AM, christophe leroy
wrote:
> Le 23/12/2017 à 16:57, Guenter Roeck a écrit :
>>
>> On 12/23/2017 05:48 AM, Greg KH wrote:
>>>
>>> On Sat, Dec 23, 2017 at 06:55:25PM +0800, Yisheng Xie wrote:
Hi all,
When I tried to use devm_ioremap function and review related code, I
found
devm_ioremap and devm_ioremap_nocache is almost the same with each
other,
except one use ioremap while the other use ioremap_nocache.
>>>
>>>
>>> For all arches? Really? Look at MIPS, and x86, they have different
>>> functions.
>>>
>>
>> Both mips and x86 end up mapping the same function, but other arches
>> don't.
>> mn10300 is one where ioremap and ioremap_nocache are definitely different.
>
>
> alpha: identical
> arc: identical
> arm: identical
> arm64: identical
> cris: different<==
> frv: identical
> hexagone: identical
> ia64: different<==
> m32r: identical
> m68k: identical
> metag: identical
> microblaze: identical
> mips: identical
> mn10300: different <==
> nios: identical
> openrisc: different<==
> parisc: identical
> riscv: identical
> s390: identical
> sh: identical
> sparc: identical
> tile: identical
> um: rely on asm/generic
> unicore32: identical
> x86: identical
> asm/generic (no mmu): identical
>
> So 4 among all arches seems to have ioremap() and ioremap_nocache() being
> different.
>
> Could we have a define set by the 4 arches on which ioremap() and
> ioremap_nocache() are different, something like
> HAVE_DIFFERENT_IOREMAP_NOCACHE ?
I wonder if those are actually correct or not. What I found looking at
those architectures:
- openrisc only has one driver using ioremap (drivers/net/ethernet/ethoc.c)
and that calls ioremap_nocache(). Presumably the authors went with the
implementation for ioremap that made sense (using default attributes)
rather than the one that actually works (using uncached).
- On ia64, ioremap() checks the attributes for the physical
address based on firmware tables and then picks either cached
or uncached mappings. ioremap_nocache() does the same but
returns NULL instead of a cached mapping for anything that is
not an MMIO address. Presumably it would just work to always
call ioremap().
- mn10300 appears to be wrong, broken by David Howells in
commit 83c2dc15ce82 ("MN10300: Handle cacheable PCI regions
in pci_iomap()") for any driver calling ioremap() by to get uncached
memory, if I understand the comment for commit 34f1bdee1910
("mn10300: switch to GENERIC_PCI_IOMAP") correctly: it
seems that PCI addresses include the 'uncached' bit by default
to get the right behavior, but dropping that bit breaks it.
- cris seems similar to mn10300 in hardware, using an phys address
bit for uncached access. There are two callers in arch code that
appear to rely on the cachable output of ioremap()
arch/cris/arch-v32/kernel/signal.c:
__ioremap_prot(virt_to_phys(data), PAGE_SIZE, PAGE_SIGNAL_TRAMPOLINE);
arch/cris/arch-v32/mm/intmem.c: intmem_virtual =
ioremap(MEM_INTMEM_START + RESERVED_SIZE,
It's unclear whether ioremap_nocache() actually has any users
on cris, or whether it was only added for compile-time testing,
and calling plain ioremap() would always work too (assuming we
pass the phys address with the uncached-bit set).
Arnd
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 198345] New: AMD-RNG can't find a device. Kernel 4.15rc6 with AMD Vega64
https://bugzilla.kernel.org/show_bug.cgi?id=198345 Bug ID: 198345 Summary: AMD-RNG can't find a device. Kernel 4.15rc6 with AMD Vega64 Product: Drivers Version: 2.5 Kernel Version: 4.15rc6 Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: justin2...@gmail.com Regression: No I am using a Radeon Vega 64 with Debian Buster/Sid. I try to develop with ROCm on it. I found out, that the module amd-rng can't find a device. sudo modprobe -v amd-rng insmod /lib/modules/4.15.0-rc6-custom/kernel/drivers/char/hw_random/amd-rng.ko modprobe: ERROR: could not insert 'amd_rng': No such device Can someone help me to fix this, please? The graphic card itself is recognized well. xrandr --listproviders Providers: number : 2 Provider 0: id: 0x70 cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 3 outputs: 4 associated providers: 0 name:modesetting Provider 1: id: 0x49 cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 6 outputs: 4 associated providers: 0 name:Radeon RX Vega @ pci::03:00.0 lspci | grep AMD 01:00.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] Device 1470 (rev c1) 02:00.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] Device 1471 03:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Vega 10 XT [Radeon RX Vega 64] (rev c1) 03:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Device aaf8 Thank you in advance! Best regards, Justin -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 198345] AMD-RNG can't find a device. Kernel 4.15rc6 with AMD Vega64
https://bugzilla.kernel.org/show_bug.cgi?id=198345 Alex Deucher (alexdeuc...@gmail.com) changed: What|Removed |Added CC||alexdeuc...@gmail.com --- Comment #1 from Alex Deucher (alexdeuc...@gmail.com) --- Please file this bug against the rng drivers if the gpu driver is loaded properly. Does your platform even support an rng device? -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 198345] AMD-RNG can't find a device. Kernel 4.15rc6 with AMD Vega64
https://bugzilla.kernel.org/show_bug.cgi?id=198345 --- Comment #2 from Justin J. (justin2...@gmail.com) --- xrandr --listproviders Providers: number : 2 Provider 0: id: 0x90 cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 6 outputs: 4 associated providers: 0 name:Radeon RX Vega @ pci::03:00.0 Provider 1: id: 0x46 cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 3 outputs: 4 associated providers: 0 name:modesetting sudo modprobe -v amd-rng [sudo] Passwort für justin: insmod /lib/modules/4.15.0-rc6-custom/kernel/drivers/char/hw_random/rng-core.ko insmod /lib/modules/4.15.0-rc6-custom/kernel/drivers/char/hw_random/amd-rng.ko modprobe: ERROR: could not insert 'amd_rng': No such device I loaded it properly... Seems to do the same mistake. and yes rng-core should be supported. the first time loading works. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 104481] GPU lockup Polaris 11 - AMD RX 460 and RX 550 on amd64 and on ARMv7 platforms while playing video
https://bugs.freedesktop.org/show_bug.cgi?id=104481 Bug ID: 104481 Summary: GPU lockup Polaris 11 - AMD RX 460 and RX 550 on amd64 and on ARMv7 platforms while playing video Product: Mesa Version: git Hardware: All OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel@lists.freedesktop.org Reporter: luis.p.men...@gmail.com QA Contact: dri-devel@lists.freedesktop.org Created attachment 136527 --> https://bugs.freedesktop.org/attachment.cgi?id=136527&action=edit dmesg and iomem data from lockup obtained with glretrace I am getting GPU lockups while playing video on Kodi, but it also happened with other applications that play video, while OpenGL seems to be stable. The system seem to be more sensitive to VP9 encoded videos. The freeze happens both on amd64 as well as on armv7l platforms. I am also able to reproduce GPU hangs on amd64 while replaying a glretrace obtained with kodi on arm platform. The arm dmesg and traces show a clear GPU lockup, while amd64 dmesg isn't so clear, but the user experience is just the same, complete graphical system freeze, while machine is still working with ssh or remote connections. Please find amd64 logs in attachments, including iomem, dmesg and gdb traces. In both platforms I am using Ubuntu 17.10 with Mate desktop, and lightdm session manager, with libdrm-2.4.89, mesa-17.4 at commit "radv: Implement binning on GFX9." - 6a36bfc64d2096aa338958c4605f5fc6372c07b8 and kernel https://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-4.16 at commit "drm/amdgpu: Correct the IB size of bo update mapping." - 104bd2ca1124dfd9aa904d5f5a96253ef2b580f6. Please note that the system was more stable a few weeks ago with drm-next-4.16 based on kernel 4.15-rc2, and a previous mesa version, I don't remember the actual commits, but despite it was more stable, both on arm as well as on amd64, both systems still crashed similarly, it just got more evident with these new versions. There are two distinct crash behaviours on amd64: the ones that I obtained while playing a video with kodi on amd64 and those that I obtained on amd64 by replaying an apitrace from the arm platform while playing a VP9 video with kodi. The first kind of crashes is detailed with logs kodi-processes_and_backtraces.txt and kodi-amdgpu_lockup_dmesg_and_iomem.txt. The second kind of crashes is detailed with logs glretrace-processes_and_backtraces.txt and glretrace-amdgpu_lockup_dmesg_and_iomem.txt. For some strange reason the amd64 platform is complaining about polaris11 firmware files, but they are in /lib/firmware and they taken by cloning https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git. I am using the same firmware files on armv7l and the same graphics card and it doesn't complain with the firmware. I can also provide the apitrace trace file, but it takes around 1GB of data. -- 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 104481] GPU lockup Polaris 11 - AMD RX 460 and RX 550 on amd64 and on ARMv7 platforms while playing video
https://bugs.freedesktop.org/show_bug.cgi?id=104481 --- Comment #1 from Luis Mendes --- Created attachment 136528 --> https://bugs.freedesktop.org/attachment.cgi?id=136528&action=edit Processes listing and gdb backtraces for all threads - glretrace lockup This is the process listing and gdb backtraces for all glretrace threads upon GPU hang caused by replaying with glretrace the apitrace obtained on arm platform from kodi playing a VP9 encoded video. -- 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 104481] GPU lockup Polaris 11 - AMD RX 460 and RX 550 on amd64 and on ARMv7 platforms while playing video
https://bugs.freedesktop.org/show_bug.cgi?id=104481 --- Comment #2 from Luis Mendes --- Created attachment 136529 --> https://bugs.freedesktop.org/attachment.cgi?id=136529&action=edit dmesg and iomem data from lockup obtained with kodi on amd64 This attachment contains the dmesg and iomem information retrieved after the GPU lockup occurred when playing a VP9 encoded video with kodi directly on amd64 platform. -- 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 104481] GPU lockup Polaris 11 - AMD RX 460 and RX 550 on amd64 and on ARMv7 platforms while playing video
https://bugs.freedesktop.org/show_bug.cgi?id=104481 --- Comment #3 from Luis Mendes --- Created attachment 136530 --> https://bugs.freedesktop.org/attachment.cgi?id=136530&action=edit Processes listing and gdb backtraces for all threads - kodi amd64 lockup This attachment contains the processes listing and gdb backtraces for all kodi threads, that were retrieved after the GPU lockup occurred when playing a VP9 encoded video with kodi directly on amd64 platform. -- 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 104481] GPU lockup Polaris 11 - AMD RX 460 and RX 550 on amd64 and on ARMv7 platforms while playing video
https://bugs.freedesktop.org/show_bug.cgi?id=104481 Luis Mendes changed: What|Removed |Added Severity|normal |major -- 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 198345] AMD-RNG can't find a device. Kernel 4.15rc6 with AMD Vega64
https://bugzilla.kernel.org/show_bug.cgi?id=198345 --- Comment #3 from Alex Deucher (alexdeuc...@gmail.com) --- The amdgpu driver is apparently loading fine. What does it have to do with the amd-rng driver? They are separate drivers why are you mentioning both on this bug? if you are having an issue with the amd-rng driver, please close this bug and open a rng bug or clarify what this has to do with the GPU. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 198345] AMD-RNG can't find a device. Kernel 4.15rc6 with AMD Vega64
https://bugzilla.kernel.org/show_bug.cgi?id=198345 Justin J. (justin2...@gmail.com) changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #4 from Justin J. (justin2...@gmail.com) --- Oh sorry... I did done the mistake... I got problems with hiprng to load it with the amd vega graphics. I forgot that there is an amd processor. I should drink more coffee. ;-) /closed -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4.15 0/4] Backport DC commits to fix display corruption
On 2018-01-03 12:11 PM, Carlo Caione wrote: > From: Carlo Caione > > Hi, > on several laptops [0] we are seeing display corruption when using multiple / > external displays. We already opened an issue upstream [1]. > The following 4 patches are taken from agd5f/amd-staging-drm-next and they > seem > able to solve the issue. > Can those be included in 4.15? > > Thank you, > > [0] Acer Aspire E5-553G (AMD FX-9800P RADEON R7) > Acer Aspire E5-523G (AMD E2-9010 RADEON R2) > Acer Aspire A315-21 (AMD A4-9120 RADEON R3) > Acer Aspire A515-41G (AMD A10-9620 RADEON R5) > > [1] https://bugs.freedesktop.org/show_bug.cgi?id=104319 > > Harry Wentland (1): > drm/amd/display: Both timing_sync and multisync need stream_count > 1 > > Leo (Sunpeng) Li (1): > drm/amd/display: Change frontend/backend programming sequence > > Mikita Lipski (2): > drm/amd/display: Adding DCN1 registers > drm/amd/display: Multi display synchronization logic > I'm surprised Mikita and my patches are required here. Are you sure they make a difference for display corruption or did you simply add them to make pull Leo's patch more cleanly? They're not bad changes. The "Multi display synchronization logic" patch is just very big and shouldn't have an impact expect in very unique situations. Harry > drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 54 - > drivers/gpu/drm/amd/display/dc/core/dc.c | 60 - > drivers/gpu/drm/amd/display/dc/dc.h| 3 + > drivers/gpu/drm/amd/display/dc/dc_hw_types.h | 16 ++ > .../amd/display/dc/dce110/dce110_hw_sequencer.c| 46 +++- > .../display/dc/dce110/dce110_timing_generator.c| 265 > + > .../display/dc/dce110/dce110_timing_generator.h| 6 + > .../drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c | 29 ++- > .../amd/display/dc/dcn10/dcn10_timing_generator.c | 66 - > .../amd/display/dc/dcn10/dcn10_timing_generator.h | 33 ++- > .../drm/amd/display/dc/inc/hw/timing_generator.h | 6 +- > drivers/gpu/drm/amd/display/dc/inc/hw_sequencer.h | 5 + > 12 files changed, 511 insertions(+), 78 deletions(-) > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 104475] Xorg Completely stops Respondng when running Overwatch in Wine
https://bugs.freedesktop.org/show_bug.cgi?id=104475 Michel Dänzer changed: What|Removed |Added Component|Server/General |Drivers/Gallium/radeonsi Assignee|xorg-t...@lists.x.org |dri-devel@lists.freedesktop ||.org QA Contact|xorg-t...@lists.x.org |dri-devel@lists.freedesktop ||.org Product|xorg|Mesa --- Comment #1 from Michel Dänzer --- Please attach the output of glxinfo. Is Overwatch a 64-bit or 32-bit application? -- 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: [RFC PATCH v2 00/13] Kernel based bootsplash
On 12/29/2017 06:13 PM, Jani Nikula wrote: > I think the first issue is the boot manager (e.g. grub) messing up > whatever the BIOS or GOP or whatever drew. If I don't touch any buttons, > I'd prefer the Lenovo or VAIO or NUC or whatever logo stay there. IIRC > some BIOSes let you set up your own splash if you like, though that's > not really relevant for me. So already the boot manager takeover is a > problem. > > The next issue is the framebuffer driver takeover. It's not unlike the > above, just one step further. If you like your grub image to stay there, > let it stay there. (Or, if the boot manager was nice enough to not mess > up the screen, let the BIOS image stay there.) All the way to KMS and > userspace. > > IMHO the user friendly experience is already gone by the time we reach > any kernel/userspace bootsplash. We want our command-line tools to STFU > if they don't have anything interesting to say. As a user, 99.99+% of > the time I don't care what grub or dmesg have to say. Agreed - the kernel should go out of the user's way if they want it to be silent. It's already possible, as long as KMS is not in use (since that automatically sets a mode and thus usually clears the screen). What you want is really the opposite of the kernel splash, or any splash on top of Linux (kernel or userspace) at all. Returning to cases where a splash running on Linux may be desired: I see adding to the initial logo as an interesting use case. An animation to show that the kernel hasn't crashed while booting is quite useful. Something like adding a spinning wheel underneath the initial logo helps. Macs do (or used to do) that after showing the apple, IIRC. I think this is where something simple and kernel based is helpful, vs. something userspace based. Maybe they can even build on top of each other, just like LILO used to print each letter as a confirmation of successfully executing a part of itself. Thinking of it: Loading a KMS driver basically always necessitates a mode change on variable resolution platforms such as PCs. And changing mode requires clearing the screen. Now, what if we could preload the new framebuffer with a splash, rather than a blank screen? That's not generally feasible (for example, double buffering is an implicit requirement), but who knows, maybe in the future. Just an odd idea. > Of course, with the kernel developer hat on, I want all of the clues > every time in case something goes wrong. But this shouldn't have to be > mutually exclusive. I agree - that's why it's important to be able to disable the bootsplash by changing the kernel cmdline. Max ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 104481] GPU lockup Polaris 11 - AMD RX 460 and RX 550 on amd64 and on ARMv7 platforms while playing video
https://bugs.freedesktop.org/show_bug.cgi?id=104481 --- Comment #4 from Luis Mendes --- Created attachment 136532 --> https://bugs.freedesktop.org/attachment.cgi?id=136532&action=edit Kernel hung task backtrace from GPU hang caused by glretrace replay This attachment contains the first print of the kernel backtrace with the hung caused by GPU hang when replaying the apitrace of the armv7l playing the VP9 video with kodi. -- 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: [RFC PATCH v2 00/13] Kernel based bootsplash
On 12/31/2017 01:35 PM, Alan Cox wrote: > For embedded every KB counts. That is likely to remain the same for some > time because at the end of the day small devices are constrained about the > amount of SRAM you can put on die and the amount of power you can afford > for DRAM. Fascinating, thanks for the insight! Now I have a really good reason to separate the splash from fbcon. >>> this by ignoring it an adding a hole new layer on top. That doesn't >>> sound like any kind of good idea to me. >> >> Yes. It is a vast improvement over the status quo, and people are asking for >> it. And the bootsplash layer can be moved elsewhere, just change the hooks >> and keep the loading/rendering. >> >> Also, gfx driver loading isn't a dumpster fire, it mostly just works. It >> just mustn't be done 100% carelessly. > > It's a total mess (the fbcon layer loading and locking that is). Doing all > this extra kernel stuff is like sitting in a hole and instead of trying to > climb out digging the hole bigger so you've got more room to sit in it. I'm not sure what exactly you're unhappy about - are you complaining about the kernel hack in KMS drivers which allows them to kick out vesafb/efifb? Max ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH v2 00/13] Kernel based bootsplash
On 12/31/2017 01:44 PM, Alan Cox wrote: >> So fundamentally I don't think an in-kernel bootsplash is a bad idea. >> But most likely you want this on a highly embedded system, which > > It wouldn't be in kernel on such a device, it'll be in the bootstrap > before (or on a dual core device quite possibly while) the kernel data is > being uncompressed. Most displays need some time to stabilize clocks and > PLLs so you have to get the mode set up really really early on embedded > devices where in some cases you've got regulatory requirements to show > something on the display really really quickly. Consumers perceive a > second from on to displaying something as sluggish on a fixed function > device. Oh no. Thanks for the input, that changes my perspective a bit. So unless we could show it quickly enough, the kernel splash would be useful either as an addition on top of the bootloader's splash, or really aimed at fatter distros which wish to use something simple and kernel based. Max ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH v2 03/13] bootsplash: Flush framebuffer after drawing
On 12/31/2017 01:53 PM, Alan Cox wrote: > On Tue, 19 Dec 2017 15:07:53 +0100 > Oliver Neukum wrote: > >> Am Dienstag, den 19.12.2017, 14:57 +0100 schrieb Daniel Vetter: Would you like me to extend the FB API or not? >>> >>> Yes. Well for real I'd like you to do kms, so maybe you need to explain >>> why exactly you absolutely have to use fbdev (aka which driver isn't >>> supported by drm that you want to enable this on). >> >> Hi, >> >> those would be at a minimum efifb, vesafb, xenfb >> Those are obviously not sexy, but from a practical point of view >> they are the minimum you need to support. > > I think it's more constructive to look at it the other way around. What > drivers do we have that actually need to be used which don't have DRM > equivalents - and how do we fix that instead ? It's *at least* the above named drivers: efifb, vesafb, xenfb. Max ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 104481] GPU lockup Polaris 11 - AMD RX 460 and RX 550 on amd64 and on ARMv7 platforms while playing video
https://bugs.freedesktop.org/show_bug.cgi?id=104481 Luis Mendes changed: What|Removed |Added OS|All |Linux (All) -- 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: [drm_hwcomposer PATCH] Take Connection state into account. (v2)
On Wed, 2018-01-03 at 13:40 +0100, Mauro Rossi wrote:
2018-01-03 12:16 GMT+01:00 Robert Foss
mailto:robert.f...@collabora.com>>:
Hey Mauro,
Thanks for the patch! It builds and looks good to me, but I have some
suggestions however.
On Wed, 2018-01-03 at 11:10 +0100, Mauro Rossi wrote:
> These changes avoid following logcat error on integrated and
> dedicated GPUs:
>
> ... 2245 2245 E hwc-drm-resources: Could not find a suitable
> encoder/crtc for display 2
> ... 2245 2245 E hwc-drm-resources: Failed CreateDisplayPipe 56 with
> -19
> ... 2245 2245 E hwcomposer-drm: Can't initialize Drm object -19
It isn't quite clear clear which errors belong to which changes,
to make this patch a bit more bisectable it would be nice to see
independent commits created for each error.
Hi Robert,
In this case I honestly do not think that splitting would add too much value,
original commit (v1) is well documented in [1] and tackles with bug in
drmresources.cpp
which currently fails to find workable crtc -> encoder -> display output
combination
for integrated and dedicated GPUs. Besides that it was also adding DisplayPort
drm mode connector type
So changes in drmresources.cpp belong to solving "Could not find a suitable
encoder/crtc for display X" problem,
which is a show stopper for enabling mainline graphics in android-x86
Other developers observed independently that the current implementation is
"embedded oriented" and only checks the first display output,
isn't it?
The only change I did in drmconnector.cpp is to account for the additional
external drm mode connectors types
which were missing (DVID, DVII, VGA) . One question on my side: Do we need more?
Besides these minor types lists discussions, I would propose you to check with
Jim Bish if he should have the credit for the patch
and review the coding of his changes.
it would be proper to keep the original author signoff but ok to add additional
signoff/testing, etc. I am not so worried about credit for this just patch but
good to following proper procedures.
>
> (v1) There are various places where we should be really taking
> connection
> state into account before querying the properties or assuming it
> as primary. This patch fixes them.
>
> BUG=None.
> TEST=System boots up and shows UI.
>
> (v1) Signed-off-by: Jim Bish mailto:jim.b...@intel.com>>
>
> (v2) porting of original commit 76fb87e675 of android-ia master
> with additional external connector types (DisplayPort, DVID, DVII,
> VGA)
> Tested with i965 on Sandybridge and nouveau on GT120, GT610
The commit message isn't really following the usual format. It doesn't
need to include a changelog (that is typically placed between the "---"
markers in the email instead),
and it is missing a signoff from the submitter (you).
Sorry I don't have a signature, as usually my patches need sign-off from
professionals,
I'm a (crash test dummy) hobbyist..really :-)
Maybe Rob Herring, Qiang Yu or Chih-Wei could review and sign-off the proposed
patch
The BUG and TEST fields are not strictly required either, but aren't a
problem.
That part is the original Jim Bish commit message [1], my changes version is
(v2)
Sorry if I was not clear enought
> ---
> drmconnector.cpp | 4 +++-
> drmresources.cpp | 9 +++--
> 2 files changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/drmconnector.cpp b/drmconnector.cpp
> index 247f56b..145518f 100644
> --- a/drmconnector.cpp
> +++ b/drmconnector.cpp
> @@ -73,7 +73,9 @@ bool DrmConnector::internal() const {
> }
>
> bool DrmConnector::external() const {
> - return type_ == DRM_MODE_CONNECTOR_HDMIA;
> + return type_ == DRM_MODE_CONNECTOR_HDMIA || type_ ==
> DRM_MODE_CONNECTOR_DisplayPort ||
> + type_ == DRM_MODE_CONNECTOR_DVID || type_ ==
> DRM_MODE_CONNECTOR_DVII ||
> + type_ == DRM_MODE_CONNECTOR_VGA;
> }
The changes to external() should probably be broken out into it's own
commit, since external() is called elsewhere changes to it _could_
introduce issues.
Will you check the code, involving Jim Bish if necessary, about these potential
issues?
I am available to perform changes/tests, but the original maker will be better.
Cheers
Mauro
>
> bool DrmConnector::valid_type() const {
> diff --git a/drmresources.cpp b/drmresources.cpp
> index 32dd376..d582cfe 100644
> --- a/drmresources.cpp
> +++ b/drmresources.cpp
> @@ -159,7 +159,7 @@ int DrmResources::Init() {
>
>// First look for primary amongst internal connectors
>for (auto &conn : connectors_) {
> -if (conn->internal() && !found_primary) {
> +if (conn->state() == DRM_MODE_CONNECTED && conn->internal() &&
> !found_primary) {
>conn->set_display(0);
>found_primary = true;
> } else {
> @@ -170,7 +170,7 @@ int DrmResources::Init() {
>
>// Then look for primary amongst external connectors
>for (auto &conn : connectors_) {
> -if (conn->external() && !found_primary) {
> +if (conn->state() == DRM_MODE_CONNECTED && conn->external()
[Bug 104289] [regression][vega10] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring sdma0 timeout on exiting certain Steam games
https://bugs.freedesktop.org/show_bug.cgi?id=104289 Christian König changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #11 from Christian König --- Code fix is now in amd-staging-drm-next -- 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 104289] [regression][vega10] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring sdma0 timeout on exiting certain Steam games
https://bugs.freedesktop.org/show_bug.cgi?id=104289 Christian König changed: What|Removed |Added Status|RESOLVED|CLOSED -- 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
[pull] amdgpu and ttm drm-fixes-4.15
Hi Dave, Just two small fixes for 4.15: - backport of a DC change which fixes a greenish tint on some RV hw - properly handle kzalloc fail in ttm The following changes since commit 03bfd4e19b935adb8be4f7342f13395fb7f11096: Merge tag 'drm-intel-fixes-2017-12-22-1' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes (2017-12-28 05:20:07 +1000) are available in the git repository at: git://people.freedesktop.org/~agd5f/linux drm-fixes-4.15 for you to fetch changes up to 19d859a7205bc59ffc38303eb25ae394f61d21dc: drm/ttm: check the return value of kzalloc (2018-01-02 14:54:05 -0500) Xiongwei Song (1): drm/ttm: check the return value of kzalloc Yue Hin Lau (1): drm/amd/display: call set csc_default if enable adjustment is false drivers/gpu/drm/amd/display/dc/dcn10/dcn10_dpp.h | 2 +- drivers/gpu/drm/amd/display/dc/dcn10/dcn10_dpp_cm.c | 6 ++ drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c | 2 ++ drivers/gpu/drm/amd/display/dc/inc/hw/dpp.h | 2 +- drivers/gpu/drm/ttm/ttm_page_alloc.c | 2 ++ 5 files changed, 8 insertions(+), 6 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Mesa-dev] Allocator Nouveau driver, Mesa EXT_external_objects, and DRM metadata import interfaces
On 12/28/2017 10:24 AM, Miguel Angel Vico wrote: (Adding dri-devel back, and trying to respond to some comments from the different forks) James Jones wrote: Your worst case analysis above isn't far off from our HW, give or take some bits and axes here and there. We've started an internal discussion about how to lay out all the bits we need. It's hard to even enumerate them all without having a complete understanding of what capability sets are going to include, a fully-optimized implementation of the mechanism on our HW, and lot's of test scenarios though. (thanks James for most of the info below) To elaborate a bit, if we want to share an allocation across GPUs for 3D rendering, it seems we would need 12 bits to express our swizzling/tiling memory layouts for fermi+. In addition to that, maxwell uses 3 more bits for this, and we need an extra bit to identify pre-fermi representations. We also need one bit to differentiate between Tegra and desktop, and another one to indicate whether the layout is otherwise linear. Then things like whether compression is used (one more bit), and we can probably get by with 3 bits for the type of compression if we are creative. However, it'd be way easier to just track arch + page kind, which would be like 32 bits on its own. Not clear if this is an NV-only term, so for those not familiar, page kind is very loosely the equivalent of a format modifier our HW uses internally in its memory management subsystem. The value mappings vary a bit for each HW generation. Whether Z-culling and/or zero-bandwidth-clears are used may be another 3 bits. If device-local properties are included, we might need a couple more bits for caching. We may also need to express locality information, which may take at least another 2 or 3 bits. If we want to share array textures too, you also need to pass the array pitch. Is it supposed to be encoded in a modifier too? That's 64 bits on its own. So yes, as James mentioned, with some effort, we could technically fit our current allocation parameters in a modifier, but I'm still not convinced this is as future proof as it could be as our hardware grows in capabilities. Daniel Stone wrote: So I reflexively get a bit itchy when I see the kernel being used to transit magic blobs of data which are supplied by userspace, and only interpreted by different userspace. Having tiling formats hidden away means that we've had real-world bugs in AMD hardware, where we end up displaying garbage because we cannot generically reason about the buffer attributes. I'm a bit confused. Can't modifiers be specified by vendors and only interpreted by drivers? My understanding was that modifiers could actually be treated as opaque 64-bit data, in which case they would qualify as "magic blobs of data". Otherwise, it seems this wouldn't be scalable. What am I missing? Daniel Vetter wrote: I think in the interim figuring out how to expose kms capabilities better (and necessarily standardizing at least some of them which matter at the compositor level, like size limits of framebuffers) feels like the place to push the ecosystem forward. In some way Miguel's proposal looks a bit backwards, since it adds the pitch capabilities to addfb, but at addfb time you've allocated everything already, so way too late to fix things up. With modifiers we've added a very simple per-plane property to list which modifiers can be combined with which pixel formats. Tiny start, but obviously very far from all that we'll need. Not sure whether I might be misunderstanding your statement, but one of the allocator main features is negotiation of nearly optimal allocation parameters given a set of uses on different devices/engines by the capability merge operation. A client should have queried what every device/engine is capable of for the given uses, find the optimal set of capabilities, and use it for allocating a buffer. At the moment these parameters are given to KMS, they are expected to be good. If they aren't, the client didn't do things right. Rob Clark wrote: It does seem like, if possible, starting out with modifiers for now at the kernel interface would make life easier, vs trying to reinvent both kernel and userspace APIs at the same time. Userspace APIs are easier to change or throw away. Presumably by the time we get to the point of changing kernel uabi, we are already using, and pretty happy with, serialized liballoc data over the wire in userspace so it is only a matter of changing the kernel interface. I guess we can indeed start with modifiers for now, if that's what it takes to get the allocator mechanisms rolling. However, it seems to me that we won't be able to encode the same type of information included in capability sets with modifiers in all cases. For instance, if we end up encoding usage transition information in capability sets, how that would translate to modifiers? I assume display doesn't really care about a lot of the data capab
[Bug 104306] Mesa 17.3 breaks Firefox and other Xwayland apps on AMD HD7750
https://bugs.freedesktop.org/show_bug.cgi?id=104306 --- Comment #10 from eric vz --- Following up on this, it looks like my bisect wa bad. I retried commit 255573996cc997cb61be9adad3e8fcaa78db5d1f and it works fine. I will re-bisect to find the real offending commit and report when I have an answer. -- 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 06/11] dt-bindings: display: sun4i-drm: Add A83T HDMI pipeline
On Sat, Dec 30, 2017 at 10:01:58PM +0100, Jernej Skrabec wrote: > This commit adds all necessary compatibles and descriptions needed to > implement A83T HDMI pipeline. > > Mixer is already properly described, so only compatible is added. > > However, A83T TCON1, which is connected to HDMI, doesn't have channel 0, > contrary to all TCONs currently described. Because of that, TCON > documentation is extended. > > A83T features Synopsys DW HDMI controller with a custom PHY which looks > like Synopsys Gen2 PHY with few additions. Since there is no > documentation, needed properties were found out through experimentation > and reading BSP code. > > At the end, example is added for newer SoCs, which features DE2 and DW > HDMI. > > Signed-off-by: Jernej Skrabec > --- > .../bindings/display/sunxi/sun4i-drm.txt | 188 > - > 1 file changed, 181 insertions(+), 7 deletions(-) > > diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt > b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt > index 9f073af4c711..3eca258096a5 100644 > --- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt > +++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt > @@ -64,6 +64,40 @@ Required properties: > first port should be the input endpoint. The second should be the > output, usually to an HDMI connector. > > +DWC HDMI TX Encoder > +- > + > +The HDMI transmitter is a Synopsys DesignWare HDMI 1.4 TX controller IP > +with Allwinner's own PHY IP. It supports audio and video outputs and CEC. > + > +These DT bindings follow the Synopsys DWC HDMI TX bindings defined in > +Documentation/devicetree/bindings/display/bridge/dw_hdmi.txt with the > +following device-specific properties. > + > +Required properties: > + > + - compatible: value must be one of: > +* "allwinner,sun8i-a83t-dw-hdmi" > + - reg: two pairs of base address and size of memory-mapped region, first > +for controller and second for PHY > +registers. Seems like the phy should be a separate node and use the phy binding. You can use the phy binding even if you don't use the kernel phy framework... > + - reg-io-width: See dw_hdmi.txt. Shall be 1. > + - interrupts: HDMI interrupt number > + - clocks: phandles to the clocks feeding the HDMI encoder > +* iahb: the HDMI bus clock > +* isfr: the HDMI register clock > +* tmds: the HDMI tmds clock > + - clock-names: the clock names mentioned above > + - resets: phandles to the reset controllers driving the encoder > +* ctrl: the reset line for the controller > +* phy: the reset line for the PHY > + - reset-names: the reset names mentioned above > + > + - ports: A ports node with endpoint definitions as defined in > +Documentation/devicetree/bindings/media/video-interfaces.txt. The > +first port should be the input endpoint. The second should be the > +output, usually to an HDMI connector. > + > TV Encoder > -- > > @@ -94,18 +128,17 @@ Required properties: > * allwinner,sun7i-a20-tcon > * allwinner,sun8i-a33-tcon > * allwinner,sun8i-a83t-tcon-lcd > + * allwinner,sun8i-a83t-tcon-tv > * allwinner,sun8i-v3s-tcon > - reg: base address and size of memory-mapped region > - interrupts: interrupt associated to this IP > - - clocks: phandles to the clocks feeding the TCON. Three are needed: > + - clocks: phandles to the clocks feeding the TCON. One is needed: > - 'ahb': the interface clocks > - - 'tcon-ch0': The clock driving the TCON channel 0 > - resets: phandles to the reset controllers driving the encoder > - "lcd": the reset line for the TCON channel 0 > > - clock-names: the clock names mentioned above > - reset-names: the reset names mentioned above > - - clock-output-names: Name of the pixel clock created > > - ports: A ports node with endpoint definitions as defined in >Documentation/devicetree/bindings/media/video-interfaces.txt. The > @@ -119,11 +152,31 @@ Required properties: >channel the endpoint is associated to. If that property is not >present, the endpoint number will be used as the channel number. > > -On SoCs other than the A33 and V3s, there is one more clock required: > +Following compatibles: > + * allwinner,sun4i-a10-tcon > + * allwinner,sun5i-a13-tcon > + * allwinner,sun6i-a31-tcon > + * allwinner,sun6i-a31s-tcon > + * allwinner,sun7i-a20-tcon > + * allwinner,sun8i-a33-tcon > + * allwinner,sun8i-a83t-tcon-lcd > + * allwinner,sun8i-v3s-tcon > +have additional required properties: > + - 'tcon-ch0': The clock driving the TCON channel 0 tcon-ch0 is a clock name, not a property. > + - clock-output-names: Name of the pixel clock created > + > +For following compatibles: > + * allwinner,sun4i-a10-tcon > + * allwinner,sun5i-a13-tcon > + * allwinner,sun6i-a31-tcon > + * allwinner,sun6i-a31s-tcon > + * allwinner,sun7i-a20-tcon > + * allwinner,sun8i-a83t-tcon-tv > +there is one
Radeon rv250 GPU acceleration broken in 4.15-rc6
Beacuse of PTI, I decided to test 4.15-rc6 on most of my test machines. And I happened to notice a radeon problem on RV250 era card with no monitor attached. 4.15-rc1 and earlier kernels did not show these errors, not kernels between rc1 and rc6 have been tested yet. The messages in dmes are strange, like 2 threads trying to poke the card instead of one? Or is it just rrying AGP mode and then PCI mode and this double output is OK? [4.777185] [drm] radeon kernel modesetting enabled. [4.779418] [drm] initializing kernel modesetting (RV250 0x1002:0x4966 0x1458:0x4010 0x01). [4.779888] agpgart-amdk7 :00:00.0: AGP 2.0 bridge [4.779963] agpgart-amdk7 :00:00.0: putting AGP V2 device into 4x mode [4.780106] radeon :01:05.0: putting AGP V2 device into 4x mode [4.780179] radeon :01:05.0: GTT: 512M 0xC000 - 0xDFFF [4.780249] radeon :01:05.0: VRAM: 128M 0xE000 - 0xE7FF (64M used) [4.780344] [drm] Detected VRAM RAM=128M, BAR=128M [4.780405] [drm] RAM width 128bits DDR [4.780622] [TTM] Zone kernel: Available graphics memory: 439294 kiB [4.780686] [TTM] Zone highmem: Available graphics memory: 1032930 kiB [4.780749] [TTM] Initializing pool allocator [4.780898] [drm] radeon: 64M of VRAM memory ready [4.780961] [drm] radeon: 512M of GTT memory ready. [4.783068] radeon :01:05.0: WB disabled [4.783166] radeon :01:05.0: fence driver on ring 0 use gpu addr 0xc000 and cpu addr 0xf6a59461 [4.783261] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [4.783323] [drm] Driver supports precise vblank timestamp query. [4.783447] [drm] radeon: irq initialized. [4.783509] [drm] Loading R200 Microcode [4.819844] [drm] radeon: ring at 0xC0001000 [4.923034] [drm:r100_ring_test [radeon]] *ERROR* radeon: ring test failed (scratch(0x15E4)=0xCAFEDEAD) [4.923181] [drm:r100_cp_init [radeon]] *ERROR* radeon: cp isn't working (-22). [4.923271] radeon :01:05.0: failed initializing CP (-22). [4.923332] radeon :01:05.0: Disabling GPU acceleration [5.025789] [drm:r100_cp_fini [radeon]] *ERROR* Wait for CP idle timeout, shutting down CP. [5.026022] [drm] radeon: cp finalized [5.026128] [drm] radeon: cp finalized [5.026223] [TTM] Finalizing pool allocator [5.027245] [TTM] Zone kernel: Used memory at exit: 0 kiB [5.027331] [TTM] Zone highmem: Used memory at exit: 0 kiB [5.027397] [drm] radeon: ttm finalized [5.027468] [drm] Forcing AGP to PCI mode [5.027886] radeon :01:05.0: VRAM: 128M 0xE000 - 0xE7FF (64M used) [5.028577] radeon :01:05.0: GTT: 512M 0xC000 - 0xDFFF [5.028671] [drm] Detected VRAM RAM=128M, BAR=128M [5.028730] [drm] RAM width 128bits DDR [5.028942] [TTM] Zone kernel: Available graphics memory: 439294 kiB [5.029005] [TTM] Zone highmem: Available graphics memory: 1032930 kiB [5.029066] [TTM] Initializing pool allocator [5.029216] [drm] radeon: 64M of VRAM memory ready [5.029277] [drm] radeon: 512M of GTT memory ready. [5.029342] [drm] GART: num cpu pages 131072, num gpu pages 131072 [5.034222] [drm] PCI GART of 512M enabled (table at 0x3560). [5.034393] radeon :01:05.0: WB disabled [5.034465] radeon :01:05.0: fence driver on ring 0 use gpu addr 0xc000 and cpu addr 0x516b4fc4 [5.034557] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [5.034618] [drm] Driver supports precise vblank timestamp query. [5.034729] [drm] radeon: irq initialized. [5.034984] [drm] radeon: ring at 0xC0001000 [5.138470] [drm:r100_ring_test [radeon]] *ERROR* radeon: ring test failed (scratch(0x15E4)=0xCAFEDEAD) [5.138618] [drm:r100_cp_init [radeon]] *ERROR* radeon: cp isn't working (-22). [5.138704] radeon :01:05.0: failed initializing CP (-22). [5.138764] radeon :01:05.0: Disabling GPU acceleration [5.241223] [drm:r100_cp_fini [radeon]] *ERROR* Wait for CP idle timeout, shutting down CP. [5.241408] [drm] radeon: cp finalized [5.243484] [drm] No TV DAC info found in BIOS [5.243659] [drm] Radeon Display Connectors [5.243719] [drm] Connector 0: [5.243776] [drm] VGA-1 [5.243833] [drm] DDC: 0x60 0x60 0x60 0x60 0x60 0x60 0x60 0x60 [5.243894] [drm] Encoders: [5.243951] [drm] CRT1: INTERNAL_DAC1 [5.244064] [drm] Connector 1: [5.244120] [drm] DVI-I-1 [5.244176] [drm] HPD1 [5.244231] [drm] DDC: 0x64 0x64 0x64 0x64 0x64 0x64 0x64 0x64 [5.244291] [drm] Encoders: [5.244346] [drm] CRT2: INTERNAL_DAC2 [5.244404] [drm] DFP1: INTERNAL_TMDS1 [5.244460] [drm] Connector 2: [5.244516] [drm] SVIDEO-1 [5.244571] [drm] Encoders: [5.244626] [drm] TV1: INTERNAL_DAC2 [5.262348] [drm] Cannot find any crtc or sizes [5.262491] [drm] Ini
Re: Radeon rv250 GPU acceleration broken in 4.15-rc6
> Beacuse of PTI, I decided to test 4.15-rc6 on most of my test machines. > And I happened to notice a radeon problem on RV250 era card with no > monitor attached. 4.15-rc1 and earlier kernels did not show these > errors, not kernels between rc1 and rc6 have been tested yet. Sorry, I can not reproduce it, so it looks like random noise from an old computer. About 10 reboots later, I have not managed to reproduce this problem. -- Meelis Roos (mr...@linux.ee) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC 1/3] drm/msm/mdp5: Add global state as a private atomic object
On Wed, Jan 3, 2018 at 6:32 AM, Archit Taneja wrote:
>
>
> On 12/21/2017 03:26 PM, Daniel Vetter wrote:
>>
>> On Thu, Dec 21, 2017 at 11:44:23AM +0530, Archit Taneja wrote:
>>>
>>> Global shared resources (hwpipes, hwmixers and SMP) for MDP5 are
>>> implemented as a part of atomic state by subclassing drm_atomic_state.
>>>
>>> The preferred approach is to use the drm_private_obj infrastructure
>>> available in the atomic core.
>>>
>>> mdp5_global_state is introduced as a drm atomic private object. The two
>>> funcs mdp5_get_global_state() and mdp5_get_existing_global_state() are
>>> the two variants that will be used to access mdp5_global_state.
>>>
>>> This will replace the existing mdp5_state struct (which subclasses
>>> drm_atomic_state) and the funcs around it. These will be removed later
>>> once we mdp5_global_state is put to use everywhere.
>>>
>>> Signed-off-by: Archit Taneja
>>> ---
>>> drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c | 86
>>> +
>>> drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h | 27 +++
>>> 2 files changed, 113 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
>>> b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
>>> index f7c0698fec40..dfc4d81124d5 100644
>>> --- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
>>> +++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
>>> @@ -106,6 +106,86 @@ static void mdp5_swap_state(struct msm_kms *kms,
>>> struct drm_atomic_state *state)
>>> swap(to_kms_state(state)->state, mdp5_kms->state);
>>> }
>>> +/* Global/shared object state funcs */
>>> +
>>> +/*
>>> + * This is a helper that returns the private state currently in
>>> operation.
>>> + * Note that this would return the "old_state" if called in the atomic
>>> check
>>> + * path, and the "new_state" after the atomic swap has been done.
>>> + */
>>> +struct mdp5_global_state *
>>> +mdp5_get_existing_global_state(struct mdp5_kms *mdp5_kms)
>>> +{
>>> + return to_mdp5_global_state(mdp5_kms->glob_base.state);
>>
>>
>> This doesn't match the existing state stuff for everything else. Here you
>> look at the global state, but not at the one hanging off drm_atomic_state.
>>
>> Maybe we should add a drm_atomic_get_existing_private_obj_state function
>> to make this easier?
>>
>> I'm also not 100% sure on what semantics you want precisely.
>
>
> I just wanted a func that returns me the private obj's state that is
> currently
> "in use". I.e, the old state pre-swap, and the new state post-swap. If I use
> drm_atomic_get_private_obj_state() after the swap has occurred, I get the
> old
> state back. In other words, there aren't funcs for private objs like
> drm_atomic_get_new_crtc_state() and drm_atomic_get_old_crtc_state() that we
> can use. I'll go through the code again carefully to see if my understanding
> isn't screwed up.
>
>
>>
>>
>>> +}
>>> +
>>> +/*
>>> + * This acquires the modeset lock set aside for global state, creates
>>> + * a new duplicated private object state.
>>> + */
>>> +struct mdp5_global_state *mdp5_get_global_state(struct drm_atomic_state
>>> *s)
>>> +{
>>> + struct msm_drm_private *priv = s->dev->dev_private;
>>> + struct mdp5_kms *mdp5_kms = to_mdp5_kms(to_mdp_kms(priv->kms));
>>> + struct drm_private_state *priv_state;
>>> + int ret;
>>> +
>>> + ret = drm_modeset_lock(&mdp5_kms->glob_state_lock,
>>> s->acquire_ctx);
>>> + if (ret)
>>> + return ERR_PTR(ret);
>>> +
>>> + priv_state = drm_atomic_get_private_obj_state(s,
>>> &mdp5_kms->glob_base);
>>> + if (IS_ERR(priv_state))
>>> + return ERR_CAST(priv_state);
>>> +
>>> + return to_mdp5_global_state(priv_state);
>>> +}
>>> +
>>> +static struct drm_private_state *
>>> +mdp5_global_duplicate_state(struct drm_private_obj *obj)
>>> +{
>>> + struct mdp5_global_state *state;
>>> +
>>> + state = kmemdup(obj->state, sizeof(*state), GFP_KERNEL);
>>> + if (!state)
>>> + return NULL;
>>> +
>>> + __drm_atomic_helper_private_obj_duplicate_state(obj,
>>> &state->base);
>>> +
>>> + return &state->base;
>>> +}
>>> +
>>> +static void mdp5_global_destroy_state(struct drm_private_obj *obj,
>>> + struct drm_private_state *state)
>>> +{
>>> + struct mdp5_global_state *mdp5_state =
>>> to_mdp5_global_state(state);
>>> +
>>> + kfree(mdp5_state);
>>> +}
>>> +
>>> +static const struct drm_private_state_funcs mdp5_global_state_funcs = {
>>> + .atomic_duplicate_state = mdp5_global_duplicate_state,
>>> + .atomic_destroy_state = mdp5_global_destroy_state,
>>> +};
>>> +
>>> +static int mdp5_global_obj_init(struct mdp5_kms *mdp5_kms)
>>> +{
>>> + struct mdp5_global_state *state;
>>> +
>>> + state = kzalloc(sizeof(*state), GFP_KERNEL);
>>> + if (!state)
>>> + return -ENOMEM;
>>> +
>>> + drm_modeset_lock_init(&mdp5_kms->glob_state_lock);
>>
>>
>> I thought a bit the last few days about
[PATCH 1/3] Add meson build system
This patch adds a complete meson build system, including tests and install. It has the necessary hooks to allow it be used as a subproject for other meson based builds such as mesa. Signed-off-by: Dylan Baker --- .editorconfig | 4 +- amdgpu/.editorconfig| 5 +- amdgpu/meson.build | 70 +++- data/meson.build| 27 +++- etnaviv/meson.build | 64 ++- exynos/meson.build | 53 +- freedreno/meson.build | 82 - intel/meson.build | 111 +++- libkms/meson.build | 75 +++- man/meson.build | 66 ++- meson.build | 378 +- meson_options.txt | 38 - nouveau/meson.build | 65 ++- omap/meson.build| 53 +- radeon/meson.build | 65 ++- tegra/meson.build | 52 +- tests/amdgpu/meson.build| 40 - tests/etnaviv/meson.build | 54 +- tests/exynos/meson.build| 54 +- tests/kms/meson.build | 54 +- tests/kmstest/meson.build | 28 +++- tests/meson.build | 85 - tests/modeprint/meson.build | 29 +++- tests/nouveau/meson.build | 30 +++- tests/proptest/meson.build | 30 +++- tests/radeon/meson.build| 27 +++- tests/tegra/meson.build | 27 +++- tests/util/meson.build | 37 - tests/vbltest/meson.build | 28 +++- vc4/meson.build | 28 +++- 30 files changed, 1759 insertions(+) create mode 100644 amdgpu/meson.build create mode 100644 data/meson.build create mode 100644 etnaviv/meson.build create mode 100644 exynos/meson.build create mode 100644 freedreno/meson.build create mode 100644 intel/meson.build create mode 100644 libkms/meson.build create mode 100644 man/meson.build create mode 100644 meson.build create mode 100644 meson_options.txt create mode 100644 nouveau/meson.build create mode 100644 omap/meson.build create mode 100644 radeon/meson.build create mode 100644 tegra/meson.build create mode 100644 tests/amdgpu/meson.build create mode 100644 tests/etnaviv/meson.build create mode 100644 tests/exynos/meson.build create mode 100644 tests/kms/meson.build create mode 100644 tests/kmstest/meson.build create mode 100644 tests/meson.build create mode 100644 tests/modeprint/meson.build create mode 100644 tests/nouveau/meson.build create mode 100644 tests/proptest/meson.build create mode 100644 tests/radeon/meson.build create mode 100644 tests/tegra/meson.build create mode 100644 tests/util/meson.build create mode 100644 tests/vbltest/meson.build create mode 100644 vc4/meson.build diff --git a/.editorconfig b/.editorconfig index 893b7be..bbad3e6 100644 --- a/.editorconfig +++ b/.editorconfig @@ -17,3 +17,7 @@ indent_style = tab [*.m4] indent_style = space indent_size = 2 + +[meson.build,meson_options.txt] +indent_style = space +indent_size = 2 diff --git a/amdgpu/.editorconfig b/amdgpu/.editorconfig index 2528d67..0c758d6 100644 --- a/amdgpu/.editorconfig +++ b/amdgpu/.editorconfig @@ -7,3 +7,8 @@ indent_style = tab indent_size = 8 tab_width = 8 insert_final_newline = true + +[meson.build] +indent_style = space +indent_size = 2 +insert_final_newline = false diff --git a/amdgpu/meson.build b/amdgpu/meson.build new file mode 100644 index 000..13bf88b --- /dev/null +++ b/amdgpu/meson.build @@ -0,0 +1,70 @@ +# Copyright © 2017 Intel Corporation + +# 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, sublicense, 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 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 NONINFRINGEMENT. IN NO EVENT SHALL THE +# AUTHORS OR COPYRIGHT HOLDERS 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. + +files_amdgpu = files( + 'amdgpu_asic_id.c', + 'amdgpu_bo.c', + 'amdgpu_cs.c', + 'amdgpu_device.c', + 'amdgpu_gpu_info.c', + 'amdgpu_internal.h', + 'amdgpu_vamgr.c', + 'amdgpu_vm.c', + 'util_hash.c', + 'util_hash.h', + 'util_hash_table.c', + 'util_hash_table.h', +) + +libdrm_amdgpu = shared_library( + 'drm_amdgpu', + [files_amdgpu, config_file], + c_args : [ +warn_c_args, +'-DAMDGPU_ASIC_ID_TABLE="@0@"'.format(join_paths(get_
[PATCH 0/3] Meson build system
This is a third iteration of the meson build system for libdrm. This version is significantly cleaned up from the last version and uses a style more like the build system in mesa. It builds all of the drivers and tests, and the tests can be run via `ninja test`. It has support for being used as a wrapped dependency wit ext_foo variables. This means it can be used to build a mesa that requires a newer libdrm than the system provides (which can be especially useful if you can't install packages on that system) and for testing. This has been build tested only. Dylan Baker (3): Add meson build system autotools: Include meson.build files in tarball README: Add note about meson .editorconfig | 4 +- Makefile.am | 30 ++- README | 21 +- amdgpu/.editorconfig| 5 +- amdgpu/meson.build | 70 +++- data/meson.build| 27 +++- etnaviv/meson.build | 64 ++- exynos/meson.build | 53 +- freedreno/meson.build | 82 - intel/meson.build | 111 +++- libkms/meson.build | 75 +++- man/meson.build | 66 ++- meson.build | 378 +- meson_options.txt | 38 - nouveau/meson.build | 65 ++- omap/meson.build| 53 +- radeon/meson.build | 65 ++- tegra/meson.build | 52 +- tests/amdgpu/meson.build| 40 - tests/etnaviv/meson.build | 54 +- tests/exynos/meson.build| 54 +- tests/kms/meson.build | 54 +- tests/kmstest/meson.build | 28 +++- tests/meson.build | 85 - tests/modeprint/meson.build | 29 +++- tests/nouveau/meson.build | 30 +++- tests/proptest/meson.build | 30 +++- tests/radeon/meson.build| 27 +++- tests/tegra/meson.build | 27 +++- tests/util/meson.build | 37 - tests/vbltest/meson.build | 28 +++- vc4/meson.build | 28 +++- 32 files changed, 1806 insertions(+), 4 deletions(-) create mode 100644 amdgpu/meson.build create mode 100644 data/meson.build create mode 100644 etnaviv/meson.build create mode 100644 exynos/meson.build create mode 100644 freedreno/meson.build create mode 100644 intel/meson.build create mode 100644 libkms/meson.build create mode 100644 man/meson.build create mode 100644 meson.build create mode 100644 meson_options.txt create mode 100644 nouveau/meson.build create mode 100644 omap/meson.build create mode 100644 radeon/meson.build create mode 100644 tegra/meson.build create mode 100644 tests/amdgpu/meson.build create mode 100644 tests/etnaviv/meson.build create mode 100644 tests/exynos/meson.build create mode 100644 tests/kms/meson.build create mode 100644 tests/kmstest/meson.build create mode 100644 tests/meson.build create mode 100644 tests/modeprint/meson.build create mode 100644 tests/nouveau/meson.build create mode 100644 tests/proptest/meson.build create mode 100644 tests/radeon/meson.build create mode 100644 tests/tegra/meson.build create mode 100644 tests/util/meson.build create mode 100644 tests/vbltest/meson.build create mode 100644 vc4/meson.build base-commit: 831036a6f62005da9fb4a75fe043bd96ce672d27 -- git-series 0.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/3] README: Add note about meson
Signed-off-by: Dylan Baker --- README | 21 ++--- 1 file changed, 18 insertions(+), 3 deletions(-) diff --git a/README b/README index 26cab9d..58e55bc 100644 --- a/README +++ b/README @@ -15,9 +15,24 @@ with an older kernel. Compiling - -libdrm is a standard autotools package and follows the normal -configure, build and install steps. The first step is to configure -the package, which is done by running the configure shell script: +libdrm has two build systems, a legacy autotools build system, and a newer +meson build system. The meson build system is much faster, and offers a +slightly different interface, but otherwise provides much the same +feature set. + +To use it: + +meson builddir + +By default this will install into /usr/local, you can change your prefix +with --prefix=/usr (or -Dprefix=/usr to meson configure). + +Then use ninja to build and install: + +ninja -C builddir install + + +Alternatively you can invoke autotools configure: ./configure -- git-series 0.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/3] autotools: Include meson.build files in tarball
I have tested that a tarball generated by autotools can be built with meson. Signed-off-by: Dylan Baker --- Makefile.am | 30 +- 1 file changed, 29 insertions(+), 1 deletion(-) diff --git a/Makefile.am b/Makefile.am index 7b86214..66f70ca 100644 --- a/Makefile.am +++ b/Makefile.am @@ -135,7 +135,35 @@ if HAVE_VMWGFX klibdrminclude_HEADERS += $(LIBDRM_INCLUDE_VMWGFX_H_FILES) endif -EXTRA_DIST = include/drm/README +EXTRA_DIST = \ + include/drm/README \ + amdgpu/meson.build \ + etnaviv/meson.build \ + exynos/meson.build \ + freedreno/meson.build \ + intel/meson.build \ + libkms/meson.build \ + man/meson.build \ + nouveau/meson.build \ + omap/meson.build \ + radeon/meson.build \ + tests/amdgpu/meson.build \ + tests/etnaviv/meson.build \ + tests/exynos/meson.build \ + tests/kms/meson.build \ + tests/kmstest/meson.build \ + tests/modeprint/meson.build \ + tests/nouveau/meson.build \ + tests/proptest/meson.build \ + tests/radeon/meson.build \ + tests/tegra/meson.build \ + tests/util/meson.build \ + tests/vbltest/meson.build \ + tests/meson.build \ + vc4/meson.build \ + data/meson.build \ + meson.build \ + meson_options.txt copy-headers : cp -r $(kernel_source)/include/uapi/drm/*.h $(top_srcdir)/include/drm/ -- git-series 0.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 3/8] drm/i915/psr: Avoid initializing PSR if there is no sink support.
first of all sorry for not getting back sooner on this...
On Tue, Dec 19, 2017 at 09:40:01PM +, Pandiyan, Dhinakaran wrote:
>
>
>
> On Tue, 2017-12-19 at 13:29 -0800, Rodrigo Vivi wrote:
> > On Tue, Dec 19, 2017 at 05:26:54AM +, Dhinakaran Pandiyan wrote:
> > > DPCD read for the eDP is complete by the time intel_psr_init() is
> > > called, which means we can avoid initializing PSR structures and state
> > > if there is no sink support.
> > >
> > > Cc: Rodrigo Vivi
> > > Cc: Ville Syrjälä
> > > Signed-off-by: Dhinakaran Pandiyan
> > > ---
> > > drivers/gpu/drm/i915/i915_debugfs.c | 7 ++-
> > > drivers/gpu/drm/i915/intel_psr.c| 9 +
> > > 2 files changed, 15 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> > > b/drivers/gpu/drm/i915/i915_debugfs.c
> > > index 64e5a263458c..1a7b28f62570 100644
> > > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > > @@ -2532,14 +2532,19 @@ static int i915_edp_psr_status(struct seq_file
> > > *m, void *data)
> > > u32 stat[3];
> > > enum pipe pipe;
> > > bool enabled = false;
> > > + bool sink_support;
> > >
> > > if (!HAS_PSR(dev_priv))
> > > return -ENODEV;
> > >
> > > + sink_support = dev_priv->psr.sink_support;
> > > + seq_printf(m, "Sink_Support: %s\n", yesno(sink_support));
> > > + if (!sink_support)
> > > + return 0;
> > > +
> > > intel_runtime_pm_get(dev_priv);
> > >
> > > mutex_lock(&dev_priv->psr.lock);
> > > - seq_printf(m, "Sink_Support: %s\n", yesno(dev_priv->psr.sink_support));
> > > seq_printf(m, "Enabled: %s\n", yesno((bool)dev_priv->psr.enabled));
> > > seq_printf(m, "Active: %s\n", yesno(dev_priv->psr.active));
> > > seq_printf(m, "Busy frontbuffer bits: 0x%03x\n",
> > > diff --git a/drivers/gpu/drm/i915/intel_psr.c
> > > b/drivers/gpu/drm/i915/intel_psr.c
> > > index 76339cf387cb..095e0a5a8574 100644
> > > --- a/drivers/gpu/drm/i915/intel_psr.c
> > > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > > @@ -503,6 +503,9 @@ void intel_psr_enable(struct intel_dp *intel_dp,
> > > if (!crtc_state->has_psr)
> > > return;
> > >
> > > + if (WARN_ON(!CAN_PSR(dev_priv)))
> > > + return;
> >
> > hmm... I believe we will see this warning sooner than later...
> >
> > has_psr is not the same as CAN_PSR.
>
> has_psr should not be set in psr_compute_config() unless both source and
> sink have PSR. So, the warn_on is if we mess up the state preparation.
> >
> > also, btw I didn't like all this crtc_state has_psr x has_psr2. :/
> >
> > probably this series could also unify that and clean it up.
> > to many has_psr like cases.
> >
> > > +
> > > WARN_ON(dev_priv->drrs.dp);
> > > mutex_lock(&dev_priv->psr.lock);
> > > if (dev_priv->psr.enabled) {
> > > @@ -633,6 +636,9 @@ void intel_psr_disable(struct intel_dp *intel_dp,
> > > if (!old_crtc_state->has_psr)
> > > return;
> > >
> > > + if (WARN_ON(!CAN_PSR(dev_priv)))
> > > + return;
> > > +
> > > mutex_lock(&dev_priv->psr.lock);
> > > if (!dev_priv->psr.enabled) {
> > > mutex_unlock(&dev_priv->psr.lock);
> > > @@ -913,6 +919,9 @@ void intel_psr_init(struct drm_i915_private *dev_priv)
> > > dev_priv->psr_mmio_base = IS_HASWELL(dev_priv) ?
> > > HSW_EDP_PSR_BASE : BDW_EDP_PSR_BASE;
> > >
> > > + if (!dev_priv->psr.sink_support)
> > > + return;
> > > +
> >
> > Why not use CAN_PSR here?
>
>
> So that we have the right MMIO's in case we want to probe the HW with no
> sink support. I wasn't what would happen if we reg_read() on PSR
> registers without the correct MMIO base.
But isn't the goal of CAN_PSR to avoid any extra calls on platforms
that either doesn't have support nor the panel? In this case we should
never being touching any register.
>
> >
> > > /* Per platform default: all disabled. */
> > > if (i915_modparams.enable_psr == -1)
> > > i915_modparams.enable_psr = 0;
> > > --
> > > 2.11.0
> > >
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[GIT PULL] etnaviv-next for 4.16
Hi Dave, sorry for getting this to you a bit late, but things didn't align before the holidays. As 4.15 seems to go to -rc8 I hope we are still in time to land this. Highlights this time: 1. Fix for a nasty Kconfig dependency chain issue from Philipp. 2. Occlusion query buffer address added to the cmdstream validator by Christian. 3. Fixes and cleanups to the job handling from me. This allows us to turn on the GPU performance profiling added in the last cycle. It is also prep work for hooking in the DRM GPU scheduler, which I hope to land for the next cycle. Regards, Lucas The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323: Linux 4.15-rc1 (2017-11-26 16:01:47 -0800) are available in the Git repository at: https://git.pengutronix.de/git/lst/linux etnaviv/next for you to fetch changes up to 2f20fc4fc9db236dc3806a93e78c7575c9561590: drm/etnaviv: use memset32 to init pagetable (2018-01-02 17:36:53 +0100) Christian Gmeiner (1): drm/etnaviv: add sensitive state for occlusion query address Lucas Stach (29): drm/etnaviv: fix GPU vs sync point race drm/etnaviv: split obj locks in different classes depending on the obj type drm/etnaviv: add lockdep annotation for userptr object population drm/etnaviv: fold __etnaviv_gem_new into caller drm/etnaviv: change return type of etnaviv_gem_obj_add to void drm/etnaviv: get rid of userptr worker drm/etnaviv: remove -EAGAIN handling from submit path drm/etnaviv: remove stale TODO in etnaviv_gpu_submit drm/etnaviv: don't flush workqueue in etnaviv_gpu_wait_obj_inactive drm/etnaviv: remove switch_context member from etnaviv_gpu drm/etnaviv: move workqueue to be per GPU drm/etnaviv: hold GPU lock while inserting END command drm/etnaviv: add lockdep annotations to buffer manipulation functions drm/etnaviv: simplify submit_create drm/etnaviv: move object fence attachment to gem_submit path drm/etnaviv: rename submit fence to out_fence drm/etnaviv: attach in fence to submit and move fence wait to fence_sync drm/etnaviv: move object unpinning to submit cleanup drm/etnaviv: move ww_acquire_ctx out of submit object drm/etnaviv: refcount the submit object drm/etnaviv: move PMRs to submit object drm/etnaviv: move exec_state to submit object drm/etnaviv: use submit exec_state for perfmon sampling drm/etnaviv: move cmdbuf into submit object drm/etnaviv: move GPU active handling to bo pin/unpin drm/etnaviv: couple runtime PM management to submit object lifetime drm/etnaviv: re-enable perfmon support drm/etnaviv: move submit free out of critical section drm/etnaviv: use memset32 to init pagetable Markus Elfring (1): drm/etnaviv: Improve unlocking of a mutex in etnaviv_iommu_map_gem() Philipp Zabel (1): drm/etnaviv: make THERMAL selectable drivers/gpu/drm/etnaviv/Kconfig | 9 ++ drivers/gpu/drm/etnaviv/etnaviv_buffer.c | 40 ++--- drivers/gpu/drm/etnaviv/etnaviv_cmd_parser.c | 1 + drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.c | 29 +- drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.h | 18 +--- drivers/gpu/drm/etnaviv/etnaviv_drv.c| 22 + drivers/gpu/drm/etnaviv/etnaviv_drv.h| 14 +-- drivers/gpu/drm/etnaviv/etnaviv_dump.c | 23 ++--- drivers/gpu/drm/etnaviv/etnaviv_gem.c| 197 + drivers/gpu/drm/etnaviv/etnaviv_gem.h| 22 +++-- drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c | 7 +- drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c | 199 ++--- drivers/gpu/drm/etnaviv/etnaviv_gpu.c| 215 - drivers/gpu/drm/etnaviv/etnaviv_gpu.h| 11 +-- drivers/gpu/drm/etnaviv/etnaviv_iommu.c | 5 +- drivers/gpu/drm/etnaviv/etnaviv_iommu_v2.c | 2 +- drivers/gpu/drm/etnaviv/etnaviv_mmu.c| 14 ++- drivers/gpu/drm/etnaviv/etnaviv_perfmon.c| 4 +- drivers/gpu/drm/etnaviv/etnaviv_perfmon.h| 2 +- 19 files changed, 323 insertions(+), 511 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] Add meson build system
Quoting Dylan Baker (2018-01-03 13:31:28) > diff --git a/freedreno/meson.build b/freedreno/meson.build > new file mode 100644 > index 000..47d6e44 > --- /dev/null > +++ b/freedreno/meson.build > @@ -0,0 +1,82 @@ > +# Copyright © 2017 Intel Corporation > + > +# 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, sublicense, 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 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 NONINFRINGEMENT. IN NO EVENT SHALL THE > +# AUTHORS OR COPYRIGHT HOLDERS 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. > + > +files_freedreno = files( > + 'freedreno_device.c', > + 'freedreno_pipe.c', > + 'freedreno_priv.h', > + 'freedreno_ringbuffer.c', > + 'freedreno_bo.c', > + 'freedreno_bo_cache.c', > + 'msm/msm_bo.c', > + 'msm/msm_device.c', > + 'msm/msm_drm.h', > + 'msm/msm_pipe.c', > + 'msm/msm_priv.h', > + 'msm/msm_ringbuffer.c', > +) > + > +if with_freedreno_kgsl != 'false' This should be "if with_freedreno_kgsl" I've fixed that locally. > + files_freedreno += files( > +'kgsl/kgsl_bo.c', > +'kgsl/kgsl_device.c', > +'kgsl/kgsl_drm.h', > +'kgsl/kgsl_pipe.c', > +'kgsl/kgsl_priv.h', > +'kgsl/kgsl_ringbuffer.c', > +'kgsl/msm_kgsl.h', > + ) > +endif signature.asc Description: signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC v2 0/8] drm: Add generic fbdev emulation
This patchset explores the possibility of having generic fbdev emulation in DRM for drivers that supports dumb buffers which they can export. Chris pointed out a bug in the previous version. I've solved this by deferring buffer creation until fb_ops->fb_open. This works fine for fbcon as well, since the first thing it does is to call fb_open. I also had to export some functions for modular builds. Noralf. Changes since version 1: - Don't add drm_fb_helper_fb_open() and drm_fb_helper_fb_release() to DRM_FB_HELPER_DEFAULT_OPS(). (Fi.CI.STATIC) The following uses that macro and sets fb_open/close: udlfb_ops, amdgpufb_ops, drm_fb_helper_generic_fbdev_ops, nouveau_fbcon_ops, nouveau_fbcon_sw_ops, radeonfb_ops. This results in: warning: Initializer entry defined twice - Support CONFIG_DRM_KMS_HELPER=m (kbuild test robot) ERROR: [drivers/gpu/drm/drm_kms_helper.ko] undefined! - Drop buggy patch: (Chris Wilson) drm/prime: Clear drm_gem_object->dma_buf on release - Defer buffer creation until fb_open. David Herrmann (1): drm: provide management functions for drm_file Noralf Trønnes (7): drm/ioctl: Remove trailing whitespace drm: Export some ioctl functions drm/fb-helper: Ensure driver module is pinned in fb_open() drm/fb-helper: Don't restore if fbdev is not in use drm: Handle fbdev emulation in core drm/fb-helper: Add generic fbdev emulation drm/vc4: Test generic fbdev emulation drivers/gpu/drm/drm_auth.c | 1 + drivers/gpu/drm/drm_crtc_internal.h | 4 - drivers/gpu/drm/drm_dumb_buffers.c | 1 + drivers/gpu/drm/drm_fb_helper.c | 356 +++- drivers/gpu/drm/drm_file.c | 323 ++-- drivers/gpu/drm/drm_framebuffer.c | 1 + drivers/gpu/drm/drm_internal.h | 4 - drivers/gpu/drm/drm_ioctl.c | 5 +- drivers/gpu/drm/drm_mode_config.c | 10 + drivers/gpu/drm/drm_prime.c | 1 + drivers/gpu/drm/drm_probe_helper.c | 4 + drivers/gpu/drm/vc4/vc4_drv.c | 3 - drivers/gpu/drm/vc4/vc4_kms.c | 3 +- include/drm/drm_auth.h | 3 + include/drm/drm_dumb_buffers.h | 10 + include/drm/drm_fb_helper.h | 93 ++ include/drm/drm_file.h | 2 + include/drm/drm_framebuffer.h | 3 + include/drm/drm_prime.h | 2 + 19 files changed, 680 insertions(+), 149 deletions(-) create mode 100644 include/drm/drm_dumb_buffers.h -- 2.14.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC v2 2/8] drm/ioctl: Remove trailing whitespace
Remove a couple of trailing spaces.
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/drm_ioctl.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index 4aafe4802099..b1e96fb68ea8 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -509,7 +509,7 @@ int drm_ioctl_permit(u32 flags, struct drm_file *file_priv)
return -EACCES;
/* MASTER is only for master or control clients */
- if (unlikely((flags & DRM_MASTER) &&
+ if (unlikely((flags & DRM_MASTER) &&
!drm_is_current_master(file_priv) &&
!drm_is_control_client(file_priv)))
return -EACCES;
@@ -704,7 +704,7 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
*
* ##define DRM_IOCTL_MY_DRIVER_OPERATION \
* DRM_IOW(DRM_COMMAND_BASE, struct my_driver_operation)
- *
+ *
* DRM driver private IOCTL must be in the range from DRM_COMMAND_BASE to
* DRM_COMMAND_END. Finally you need an array of &struct drm_ioctl_desc to wire
* up the handlers and set the access rights::
--
2.14.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC v2 5/8] drm/fb-helper: Don't restore if fbdev is not in use
Keep track of fbdev users and only restore fbdev in
drm_fb_helper_restore_fbdev_mode_unlocked() when in use. This avoids
fbdev being restored in drm_driver.last_close when nothing uses it.
Additionally fbdev is turned off when the last user is closing.
fbcon is a user in this context.
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/drm_fb_helper.c | 15 +++
include/drm/drm_fb_helper.h | 14 ++
2 files changed, 29 insertions(+)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 2c6adf1d80c2..f9dcc7a5761f 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -522,6 +522,9 @@ int drm_fb_helper_restore_fbdev_mode_unlocked(struct
drm_fb_helper *fb_helper)
if (READ_ONCE(fb_helper->deferred_setup))
return 0;
+ if (!atomic_read(&fb_helper->open_count))
+ return 0;
+
mutex_lock(&fb_helper->lock);
ret = restore_fbdev_mode(fb_helper);
@@ -781,6 +784,7 @@ void drm_fb_helper_prepare(struct drm_device *dev, struct
drm_fb_helper *helper,
INIT_WORK(&helper->resume_work, drm_fb_helper_resume_worker);
INIT_WORK(&helper->dirty_work, drm_fb_helper_dirty_work);
helper->dirty_clip.x1 = helper->dirty_clip.y1 = ~0;
+ atomic_set(&helper->open_count, 1);
mutex_init(&helper->lock);
helper->funcs = funcs;
helper->dev = dev;
@@ -1212,6 +1216,7 @@ EXPORT_SYMBOL(drm_fb_helper_cfb_imageblit);
* @info: fbdev registered by the helper
* @user: 1=userspace, 0=fbcon
*
+ * Increase fbdev use count.
* If &fb_ops is wrapped in a library, pin the driver module.
*/
int drm_fb_helper_fb_open(struct fb_info *info, int user)
@@ -1224,6 +1229,8 @@ int drm_fb_helper_fb_open(struct fb_info *info, int user)
return -ENODEV;
}
+ atomic_inc(&fb_helper->open_count);
+
return 0;
}
EXPORT_SYMBOL(drm_fb_helper_fb_open);
@@ -1233,6 +1240,7 @@ EXPORT_SYMBOL(drm_fb_helper_fb_open);
* @info: fbdev registered by the helper
* @user: 1=userspace, 0=fbcon
*
+ * Decrease fbdev use count and turn off if there are no users left.
* If &fb_ops is wrapped in a library, unpin the driver module.
*/
int drm_fb_helper_fb_release(struct fb_info *info, int user)
@@ -1240,6 +1248,10 @@ int drm_fb_helper_fb_release(struct fb_info *info, int
user)
struct drm_fb_helper *fb_helper = info->par;
struct drm_device *dev = fb_helper->dev;
+ if (atomic_dec_and_test(&fb_helper->open_count) &&
+ !drm_dev_is_unplugged(fb_helper->dev))
+ drm_fb_helper_blank(FB_BLANK_POWERDOWN, info);
+
if (info->fbops->owner != dev->driver->fops->owner)
module_put(dev->driver->fops->owner);
@@ -1936,6 +1948,9 @@ static int drm_fb_helper_single_fb_probe(struct
drm_fb_helper *fb_helper,
if (ret < 0)
return ret;
+ if (fb_helper->fbdev->fbops->fb_open == drm_fb_helper_fb_open)
+ atomic_set(&fb_helper->open_count, 0);
+
strcpy(fb_helper->fb->comm, "[fbcon]");
return 0;
}
diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
index a593f01ff69e..16d8773b60e3 100644
--- a/include/drm/drm_fb_helper.h
+++ b/include/drm/drm_fb_helper.h
@@ -232,6 +232,20 @@ struct drm_fb_helper {
* See also: @deferred_setup
*/
int preferred_bpp;
+
+ /**
+* @open_count:
+*
+* Keeps track of fbdev use to know when to not restore fbdev.
+*
+* Drivers that use drm_fb_helper_fb_open() as their \.fb_open
+* callback will get an initial value of 0 and get restore based on
+* actual use. Others will get an initial value of 1 which means that
+* fbdev will always be restored. Drivers that call
+* drm_fb_helper_fb_open() in their \.fb_open, thus needs to set the
+* initial value to 0 themselves.
+*/
+ atomic_t open_count;
};
/**
--
2.14.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC v2 1/8] drm: provide management functions for drm_file
From: David Herrmann
Rather than doing drm_file allocation/destruction right in the fops, lets
provide separate helpers. This decouples drm_file management from the
still-mandatory drm-fops. It prepares for use of drm_file without the
fops, both by possible separate fops implementations and APIs (not that I
am aware of any such plans), and more importantly from in-kernel use where
no real file is available.
Signed-off-by: David Herrmann
[rebased]
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/drm_file.c | 309 +++--
drivers/gpu/drm/drm_internal.h | 2 +
2 files changed, 179 insertions(+), 132 deletions(-)
diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
index b3c6e997ccdb..d208faade27e 100644
--- a/drivers/gpu/drm/drm_file.c
+++ b/drivers/gpu/drm/drm_file.c
@@ -101,6 +101,179 @@ DEFINE_MUTEX(drm_global_mutex);
static int drm_open_helper(struct file *filp, struct drm_minor *minor);
+/**
+ * drm_file_alloc - allocate file context
+ * @minor: minor to allocate on
+ *
+ * This allocates a new DRM file context. It is not linked into any context and
+ * can be used by the caller freely. Note that the context keeps a pointer to
+ * @minor, so it must be freed before @minor is.
+ *
+ * The legacy paths might require the drm_global_mutex to be held.
+ *
+ * RETURNS:
+ * Pointer to newly allocated context, ERR_PTR on failure.
+ */
+struct drm_file *drm_file_alloc(struct drm_minor *minor)
+{
+ struct drm_device *dev = minor->dev;
+ struct drm_file *file;
+ int ret;
+
+ file = kzalloc(sizeof(*file), GFP_KERNEL);
+ if (!file)
+ return ERR_PTR(-ENOMEM);
+
+ file->pid = get_pid(task_pid(current));
+ file->minor = minor;
+
+ /* for compatibility root is always authenticated */
+ file->authenticated = capable(CAP_SYS_ADMIN);
+ file->lock_count = 0;
+
+ INIT_LIST_HEAD(&file->lhead);
+ INIT_LIST_HEAD(&file->fbs);
+ mutex_init(&file->fbs_lock);
+ INIT_LIST_HEAD(&file->blobs);
+ INIT_LIST_HEAD(&file->pending_event_list);
+ INIT_LIST_HEAD(&file->event_list);
+ init_waitqueue_head(&file->event_wait);
+ file->event_space = 4096; /* set aside 4k for event buffer */
+
+ mutex_init(&file->event_read_lock);
+
+ if (drm_core_check_feature(dev, DRIVER_GEM))
+ drm_gem_open(dev, file);
+
+ if (drm_core_check_feature(dev, DRIVER_SYNCOBJ))
+ drm_syncobj_open(file);
+
+ if (drm_core_check_feature(dev, DRIVER_PRIME))
+ drm_prime_init_file_private(&file->prime);
+
+ if (dev->driver->open) {
+ ret = dev->driver->open(dev, file);
+ if (ret < 0)
+ goto out_prime_destroy;
+ }
+
+ if (drm_is_primary_client(file)) {
+ ret = drm_master_open(file);
+ if (ret)
+ goto out_close;
+ }
+
+ return file;
+
+out_close:
+ if (dev->driver->postclose)
+ dev->driver->postclose(dev, file);
+out_prime_destroy:
+ if (drm_core_check_feature(dev, DRIVER_PRIME))
+ drm_prime_destroy_file_private(&file->prime);
+ if (drm_core_check_feature(dev, DRIVER_SYNCOBJ))
+ drm_syncobj_release(file);
+ if (drm_core_check_feature(dev, DRIVER_GEM))
+ drm_gem_release(dev, file);
+ put_pid(file->pid);
+ kfree(file);
+
+ return ERR_PTR(ret);
+}
+
+static void drm_events_release(struct drm_file *file_priv)
+{
+ struct drm_device *dev = file_priv->minor->dev;
+ struct drm_pending_event *e, *et;
+ unsigned long flags;
+
+ spin_lock_irqsave(&dev->event_lock, flags);
+
+ /* Unlink pending events */
+ list_for_each_entry_safe(e, et, &file_priv->pending_event_list,
+pending_link) {
+ list_del(&e->pending_link);
+ e->file_priv = NULL;
+ }
+
+ /* Remove unconsumed events */
+ list_for_each_entry_safe(e, et, &file_priv->event_list, link) {
+ list_del(&e->link);
+ kfree(e);
+ }
+
+ spin_unlock_irqrestore(&dev->event_lock, flags);
+}
+
+/**
+ * drm_file_free - free file context
+ * @file: context to free, or NULL
+ *
+ * This destroys and deallocates a DRM file context previously allocated via
+ * drm_file_alloc(). The caller must make sure to unlink it from any contexts
+ * before calling this.
+ *
+ * The legacy paths might require the drm_global_mutex to be held.
+ *
+ * If NULL is passed, this is a no-op.
+ *
+ * RETURNS:
+ * 0 on success, or error code on failure.
+ */
+void drm_file_free(struct drm_file *file)
+{
+ struct drm_device *dev;
+
+ if (!file)
+ return;
+
+ dev = file->minor->dev;
+
+ DRM_DEBUG("pid = %d, device = 0x%lx, open_count = %d\n",
+ task_pid_nr(current),
+ (long)old_en
[RFC v2 3/8] drm: Export some ioctl functions
Export the following functions so in-kernel users can allocate
dumb buffers:
- drm_file_alloc
- drm_file_free
- drm_prime_handle_to_fd_ioctl
- drm_mode_addfb2
- drm_mode_create_dumb_ioctl
- drm_dropmaster_ioctl
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/drm_auth.c | 1 +
drivers/gpu/drm/drm_crtc_internal.h | 4
drivers/gpu/drm/drm_dumb_buffers.c | 1 +
drivers/gpu/drm/drm_file.c | 2 ++
drivers/gpu/drm/drm_framebuffer.c | 1 +
drivers/gpu/drm/drm_internal.h | 6 --
drivers/gpu/drm/drm_ioctl.c | 1 +
drivers/gpu/drm/drm_prime.c | 1 +
include/drm/drm_auth.h | 3 +++
include/drm/drm_dumb_buffers.h | 10 ++
include/drm/drm_file.h | 2 ++
include/drm/drm_framebuffer.h | 3 +++
include/drm/drm_prime.h | 2 ++
13 files changed, 27 insertions(+), 10 deletions(-)
create mode 100644 include/drm/drm_dumb_buffers.h
diff --git a/drivers/gpu/drm/drm_auth.c b/drivers/gpu/drm/drm_auth.c
index aad468d170a7..e35ed9ee0c5a 100644
--- a/drivers/gpu/drm/drm_auth.c
+++ b/drivers/gpu/drm/drm_auth.c
@@ -236,6 +236,7 @@ int drm_dropmaster_ioctl(struct drm_device *dev, void *data,
mutex_unlock(&dev->master_mutex);
return ret;
}
+EXPORT_SYMBOL(drm_dropmaster_ioctl);
int drm_master_open(struct drm_file *file_priv)
{
diff --git a/drivers/gpu/drm/drm_crtc_internal.h
b/drivers/gpu/drm/drm_crtc_internal.h
index 9ebb8841778c..86422492ad00 100644
--- a/drivers/gpu/drm/drm_crtc_internal.h
+++ b/drivers/gpu/drm/drm_crtc_internal.h
@@ -63,8 +63,6 @@ int drm_mode_getresources(struct drm_device *dev,
/* drm_dumb_buffers.c */
/* IOCTLs */
-int drm_mode_create_dumb_ioctl(struct drm_device *dev,
- void *data, struct drm_file *file_priv);
int drm_mode_mmap_dumb_ioctl(struct drm_device *dev,
void *data, struct drm_file *file_priv);
int drm_mode_destroy_dumb_ioctl(struct drm_device *dev,
@@ -164,8 +162,6 @@ void drm_fb_release(struct drm_file *file_priv);
/* IOCTL */
int drm_mode_addfb(struct drm_device *dev,
void *data, struct drm_file *file_priv);
-int drm_mode_addfb2(struct drm_device *dev,
- void *data, struct drm_file *file_priv);
int drm_mode_rmfb(struct drm_device *dev,
void *data, struct drm_file *file_priv);
int drm_mode_getfb(struct drm_device *dev,
diff --git a/drivers/gpu/drm/drm_dumb_buffers.c
b/drivers/gpu/drm/drm_dumb_buffers.c
index 39ac15ce4702..199b279f7650 100644
--- a/drivers/gpu/drm/drm_dumb_buffers.c
+++ b/drivers/gpu/drm/drm_dumb_buffers.c
@@ -90,6 +90,7 @@ int drm_mode_create_dumb_ioctl(struct drm_device *dev,
return dev->driver->dumb_create(file_priv, dev, args);
}
+EXPORT_SYMBOL(drm_mode_create_dumb_ioctl);
/**
* drm_mode_mmap_dumb_ioctl - create an mmap offset for a dumb backing storage
buffer
diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
index d208faade27e..400d44437e93 100644
--- a/drivers/gpu/drm/drm_file.c
+++ b/drivers/gpu/drm/drm_file.c
@@ -180,6 +180,7 @@ struct drm_file *drm_file_alloc(struct drm_minor *minor)
return ERR_PTR(ret);
}
+EXPORT_SYMBOL(drm_file_alloc);
static void drm_events_release(struct drm_file *file_priv)
{
@@ -273,6 +274,7 @@ void drm_file_free(struct drm_file *file)
put_pid(file->pid);
kfree(file);
}
+EXPORT_SYMBOL(drm_file_free);
static int drm_setup(struct drm_device * dev)
{
diff --git a/drivers/gpu/drm/drm_framebuffer.c
b/drivers/gpu/drm/drm_framebuffer.c
index 5a13ff29f4f0..0493977e6848 100644
--- a/drivers/gpu/drm/drm_framebuffer.c
+++ b/drivers/gpu/drm/drm_framebuffer.c
@@ -341,6 +341,7 @@ int drm_mode_addfb2(struct drm_device *dev,
return 0;
}
+EXPORT_SYMBOL(drm_mode_addfb2);
struct drm_mode_rmfb_work {
struct work_struct work;
diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
index 40179c5fc6b8..7d62e412fbb8 100644
--- a/drivers/gpu/drm/drm_internal.h
+++ b/drivers/gpu/drm/drm_internal.h
@@ -26,8 +26,6 @@
/* drm_file.c */
extern struct mutex drm_global_mutex;
-struct drm_file *drm_file_alloc(struct drm_minor *minor);
-void drm_file_free(struct drm_file *file);
void drm_lastclose(struct drm_device *dev);
/* drm_pci.c */
@@ -37,8 +35,6 @@ void drm_pci_agp_destroy(struct drm_device *dev);
int drm_pci_set_busid(struct drm_device *dev, struct drm_master *master);
/* drm_prime.c */
-int drm_prime_handle_to_fd_ioctl(struct drm_device *dev, void *data,
-struct drm_file *file_priv);
int drm_prime_fd_to_handle_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_priv);
@@ -85,8 +81,6 @@ int drm_authmagic(struct drm_device *dev, void *data,
struct drm_file *file_priv);
int drm_setmaster_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_priv);
-int drm_dropma
[RFC v2 8/8] drm/vc4: Test generic fbdev emulation
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/vc4/vc4_drv.c | 3 ---
drivers/gpu/drm/vc4/vc4_kms.c | 3 +--
2 files changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c
index ceb385fd69c5..ef8a2d3a6d1f 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.c
+++ b/drivers/gpu/drm/vc4/vc4_drv.c
@@ -152,7 +152,6 @@ static struct drm_driver vc4_drm_driver = {
DRIVER_HAVE_IRQ |
DRIVER_RENDER |
DRIVER_PRIME),
- .lastclose = drm_fb_helper_lastclose,
.irq_handler = vc4_irq,
.irq_preinstall = vc4_irq_preinstall,
.irq_postinstall = vc4_irq_postinstall,
@@ -297,8 +296,6 @@ static void vc4_drm_unbind(struct device *dev)
drm_dev_unregister(drm);
- drm_fb_cma_fbdev_fini(drm);
-
drm_mode_config_cleanup(drm);
drm_dev_unref(drm);
diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
index 4256f294c346..671c62f1b4d3 100644
--- a/drivers/gpu/drm/vc4/vc4_kms.c
+++ b/drivers/gpu/drm/vc4/vc4_kms.c
@@ -188,7 +188,6 @@ static struct drm_framebuffer *vc4_fb_create(struct
drm_device *dev,
}
static const struct drm_mode_config_funcs vc4_mode_funcs = {
- .output_poll_changed = drm_fb_helper_output_poll_changed,
.atomic_check = drm_atomic_helper_check,
.atomic_commit = vc4_atomic_commit,
.fb_create = vc4_fb_create,
@@ -219,7 +218,7 @@ int vc4_kms_load(struct drm_device *dev)
drm_mode_config_reset(dev);
if (dev->mode_config.num_connector)
- drm_fb_cma_fbdev_init(dev, 32, 0);
+ drm_fb_helper_generic_fbdev_setup(dev, 32, 0);
drm_kms_helper_poll_init(dev);
--
2.14.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
