[PATCH v4 2/4] dt-bindings: display: bridge: Add documentation for LT9611
Lontium LT9611 is a DSI to HDMI bridge which supports 2 DSI ports
and I2S port as input and one HDMI port as output
Reviewed-by: Rob Herring
Tested-by: John Stultz
Signed-off-by: Vinod Koul
---
.../display/bridge/lontium,lt9611.yaml| 176 ++
1 file changed, 176 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml
diff --git
a/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml
b/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml
new file mode 100644
index ..d60208359234
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml
@@ -0,0 +1,176 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/lontium,lt9611.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Lontium LT9611 2 Port MIPI to HDMI Bridge
+
+maintainers:
+ - Vinod Koul
+
+description: |
+ The LT9611 is a bridge device which converts DSI to HDMI
+
+properties:
+ compatible:
+enum:
+ - lontium,lt9611
+
+ reg:
+maxItems: 1
+
+ "#sound-dai-cells":
+const: 1
+
+ interrupts:
+maxItems: 1
+
+ reset-gpios:
+maxItems: 1
+description: GPIO connected to active high RESET pin.
+
+ vdd-supply:
+description: Regulator for 1.8V MIPI phy power.
+
+ vcc-supply:
+description: Regulator for 3.3V IO power.
+
+ ports:
+type: object
+
+properties:
+ "#address-cells":
+const: 1
+
+ "#size-cells":
+const: 0
+
+ port@0:
+type: object
+description: |
+ Primary MIPI port-1 for MIPI input
+
+properties:
+ reg:
+const: 0
+
+patternProperties:
+ "^endpoint(@[0-9])$":
+type: object
+additionalProperties: false
+
+properties:
+ remote-endpoint:
+$ref: /schemas/types.yaml#/definitions/phandle
+
+required:
+ - reg
+
+ port@1:
+type: object
+description: |
+ Additional MIPI port-2 for MIPI input, used in combination
+ with primary MIPI port-1 to drive higher resolution displays
+
+properties:
+ reg:
+const: 1
+
+patternProperties:
+ "^endpoint(@[0-9])$":
+type: object
+additionalProperties: false
+
+properties:
+ remote-endpoint:
+$ref: /schemas/types.yaml#/definitions/phandle
+
+required:
+ - reg
+
+ port@2:
+type: object
+description: |
+ HDMI port for HDMI output
+
+properties:
+ reg:
+const: 2
+
+patternProperties:
+ "^endpoint(@[0-9])$":
+type: object
+additionalProperties: false
+
+properties:
+ remote-endpoint:
+$ref: /schemas/types.yaml#/definitions/phandle
+
+required:
+ - reg
+
+required:
+ - "#address-cells"
+ - "#size-cells"
+ - port@0
+ - port@2
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - vdd-supply
+ - vcc-supply
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+
+i2c10 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ hdmi-bridge@3b {
+compatible = "lontium,lt9611";
+reg = <0x3b>;
+
+reset-gpios = <&tlmm 128 GPIO_ACTIVE_HIGH>;
+interrupts-extended = <&tlmm 84 IRQ_TYPE_EDGE_FALLING>;
+
+vdd-supply = <<9611_1v8>;
+vcc-supply = <<9611_3v3>;
+
+ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+reg = <0>;
+lt9611_a: endpoint {
+ remote-endpoint = <&dsi0_out>;
+};
+ };
+
+ port@1 {
+reg = <1>;
+lt9611_b: endpoint {
+ remote-endpoint = <&dsi1_out>;
+};
+ };
+
+ port@2 {
+reg = <2>;
+lt9611_out: endpoint {
+ remote-endpoint = <&hdmi_con>;
+};
+ };
+};
+ };
+};
+
+...
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 4/4] drm/msm/dsi: attach external bridge with DRM_BRIDGE_ATTACH_NO_CONNECTOR
Modern bridges do not create the connector and expect the display driver
to do so. Hence, create the drm connector in msm display driver and add
use flag DRM_BRIDGE_ATTACH_NO_CONNECTOR to attach bridges
Tested-by: John Stultz
Signed-off-by: Vinod Koul
---
drivers/gpu/drm/msm/dsi/dsi.c | 7 +--
drivers/gpu/drm/msm/dsi/dsi_manager.c | 27 +--
2 files changed, 14 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/msm/dsi/dsi.c b/drivers/gpu/drm/msm/dsi/dsi.c
index 55ea4bc2ee9c..617075e3e3f0 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.c
+++ b/drivers/gpu/drm/msm/dsi/dsi.c
@@ -219,12 +219,7 @@ int msm_dsi_modeset_init(struct msm_dsi *msm_dsi, struct
drm_device *dev,
goto fail;
}
- /*
-* check if the dsi encoder output is connected to a panel or an
-* external bridge. We create a connector only if we're connected to a
-* drm_panel device. When we're connected to an external bridge, we
-* assume that the drm_bridge driver will create the connector itself.
-*/
+ /* Initialize the internal panel or external bridge */
ext_bridge = msm_dsi_host_get_bridge(msm_dsi->host);
if (ext_bridge)
diff --git a/drivers/gpu/drm/msm/dsi/dsi_manager.c
b/drivers/gpu/drm/msm/dsi/dsi_manager.c
index 4b363bd7ddff..72cfd0a8187b 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_manager.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_manager.c
@@ -3,6 +3,7 @@
* Copyright (c) 2015, The Linux Foundation. All rights reserved.
*/
+#include
#include "msm_kms.h"
#include "dsi.h"
@@ -689,7 +690,7 @@ struct drm_bridge *msm_dsi_manager_bridge_init(u8 id)
bridge = &dsi_bridge->base;
bridge->funcs = &dsi_mgr_bridge_funcs;
- ret = drm_bridge_attach(encoder, bridge, NULL, 0);
+ ret = drm_bridge_attach(encoder, bridge, NULL,
DRM_BRIDGE_ATTACH_NO_CONNECTOR);
if (ret)
goto fail;
@@ -709,7 +710,6 @@ struct drm_connector *msm_dsi_manager_ext_bridge_init(u8 id)
struct drm_encoder *encoder;
struct drm_bridge *int_bridge, *ext_bridge;
struct drm_connector *connector;
- struct list_head *connector_list;
int_bridge = msm_dsi->bridge;
ext_bridge = msm_dsi->external_bridge =
@@ -717,22 +717,21 @@ struct drm_connector *msm_dsi_manager_ext_bridge_init(u8
id)
encoder = msm_dsi->encoder;
- /* link the internal dsi bridge to the external bridge */
- drm_bridge_attach(encoder, ext_bridge, int_bridge, 0);
-
- /*
-* we need the drm_connector created by the external bridge
-* driver (or someone else) to feed it to our driver's
-* priv->connector[] list, mainly for msm_fbdev_init()
+ /* link the internal dsi bridge to the external bridge and attach
+* the connector, we are supporting DRM_BRIDGE_ATTACH_NO_CONNECTOR
+* so always create connector
*/
- connector_list = &dev->mode_config.connector_list;
+ drm_bridge_attach(encoder, ext_bridge, int_bridge,
DRM_BRIDGE_ATTACH_NO_CONNECTOR);
- list_for_each_entry(connector, connector_list, head) {
- if (drm_connector_has_possible_encoder(connector, encoder))
- return connector;
+ connector = drm_bridge_connector_init(dev, encoder);
+ if (IS_ERR(connector)) {
+ DRM_DEV_ERROR(dev->dev, "drm_bridge_connector_init failed:
%ld\n",
+ PTR_ERR(connector));
+ return ERR_PTR(-ENODEV);
}
- return ERR_PTR(-ENODEV);
+ drm_connector_attach_encoder(connector, msm_dsi->encoder);
+ return connector;
}
void msm_dsi_manager_bridge_destroy(struct drm_bridge *bridge)
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 1/4] dt-bindings: vendor-prefixes: Add Lontium vendor prefix
Add prefix for Lontium Semiconductor Corporation Acked-by: Rob Herring Tested-by: John Stultz Signed-off-by: Vinod Koul --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 9aeab66be85f..31cdb21a3d22 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -595,6 +595,8 @@ patternProperties: description: Logic Technologies Limited "^longcheer,.*": description: Longcheer Technology (Shanghai) Co., Ltd. + "^lontium,.*": +description: Lontium Semiconductor Corporation "^loongson,.*": description: Loongson Technology Corporation Limited "^lsi,.*": -- 2.26.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 3/4] drm/bridge: Introduce LT9611 DSI to HDMI bridge
Lontium Lt9611 is a DSI to HDMI bridge which supports two DSI ports and
I2S port as an input and HDMI port as output
Co-developed-by: Bjorn Andersson
Signed-off-by: Bjorn Andersson
Co-developed-by: Srinivas Kandagatla
Signed-off-by: Srinivas Kandagatla
Tested-by: John Stultz
Signed-off-by: Vinod Koul
---
drivers/gpu/drm/bridge/Kconfig | 13 +
drivers/gpu/drm/bridge/Makefile |1 +
drivers/gpu/drm/bridge/lontium-lt9611.c | 1174 +++
3 files changed, 1188 insertions(+)
create mode 100644 drivers/gpu/drm/bridge/lontium-lt9611.c
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 43271c21d3fc..c7f0dacfb57a 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -48,6 +48,19 @@ config DRM_DISPLAY_CONNECTOR
on ARM-based platforms. Saying Y here when this driver is not needed
will not cause any issue.
+config DRM_LONTIUM_LT9611
+ tristate "Lontium LT9611 DSI/HDMI bridge"
+ select SND_SOC_HDMI_CODEC if SND_SOC
+ depends on OF
+ select DRM_PANEL_BRIDGE
+ select DRM_KMS_HELPER
+ select REGMAP_I2C
+ help
+ Driver for Lontium LT9611 DSI to HDMI bridge
+ chip driver that converts dual DSI and I2S to
+ HDMI signals
+ Please say Y if you have such hardware.
+
config DRM_LVDS_CODEC
tristate "Transparent LVDS encoders and decoders support"
depends on OF
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index d63d4b7e4347..7d7c123a95e4 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -2,6 +2,7 @@
obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o
obj-$(CONFIG_DRM_CHRONTEL_CH7033) += chrontel-ch7033.o
obj-$(CONFIG_DRM_DISPLAY_CONNECTOR) += display-connector.o
+obj-$(CONFIG_DRM_LONTIUM_LT9611) += lontium-lt9611.o
obj-$(CONFIG_DRM_LVDS_CODEC) += lvds-codec.o
obj-$(CONFIG_DRM_MEGACHIPS_STDP_GE_B850V3_FW) +=
megachips-stdp-ge-b850v3-fw.o
obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
diff --git a/drivers/gpu/drm/bridge/lontium-lt9611.c
b/drivers/gpu/drm/bridge/lontium-lt9611.c
new file mode 100644
index ..155e3ebdc5a8
--- /dev/null
+++ b/drivers/gpu/drm/bridge/lontium-lt9611.c
@@ -0,0 +1,1174 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2018, The Linux Foundation. All rights reserved.
+ * Copyright (c) 2019-2020. Linaro Limited.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include
+#include
+#include
+#include
+#include
+
+#define EDID_SEG_SIZE 256
+#define EDID_LEN 32
+#define EDID_LOOP 8
+#define KEY_DDC_ACCS_DONE 0x02
+#define DDC_NO_ACK 0x50
+
+#define LT9611_4LANES 0
+
+struct lt9611 {
+ struct device *dev;
+ struct drm_bridge bridge;
+ struct drm_connector connector;
+
+ struct regmap *regmap;
+
+ struct device_node *dsi0_node;
+ struct device_node *dsi1_node;
+ struct mipi_dsi_device *dsi0;
+ struct mipi_dsi_device *dsi1;
+ struct platform_device *audio_pdev;
+
+ bool ac_mode;
+
+ struct gpio_desc *reset_gpio;
+ struct gpio_desc *enable_gpio;
+
+ bool power_on;
+ bool sleep;
+
+ struct regulator_bulk_data supplies[2];
+
+ struct i2c_client *client;
+
+ enum drm_connector_status status;
+
+ u8 edid_buf[EDID_SEG_SIZE];
+ u32 vic;
+};
+
+#define LT9611_PAGE_CONTROL0xff
+
+static const struct regmap_range_cfg lt9611_ranges[] = {
+ {
+ .name = "register_range",
+ .range_min = 0,
+ .range_max = 0x85ff,
+ .selector_reg = LT9611_PAGE_CONTROL,
+ .selector_mask = 0xff,
+ .selector_shift = 0,
+ .window_start = 0,
+ .window_len = 0x100,
+ },
+};
+
+static const struct regmap_config lt9611_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
+ .max_register = 0x,
+ .ranges = lt9611_ranges,
+ .num_ranges = ARRAY_SIZE(lt9611_ranges),
+};
+
+struct lt9611_mode {
+ u16 hdisplay;
+ u16 vdisplay;
+ u8 vrefresh;
+ u8 lanes;
+ u8 intfs;
+};
+
+static struct lt9611_mode lt9611_modes[] = {
+ { 3840, 2160, 30, 4, 2 }, /* 3840x2160 24bit 30Hz 4Lane 2ports */
+ { 1920, 1080, 60, 4, 1 }, /* 1080P 24bit 60Hz 4lane 1port */
+ { 1920, 1080, 30, 3, 1 }, /* 1080P 24bit 30Hz 3lane 1port */
+ { 1920, 1080, 24, 3, 1 },
+ { 720, 480, 60, 4, 1 },
+ { 720, 576, 50, 2, 1 },
+ { 640, 480, 60, 2, 1 },
+};
+
+static struct lt9611 *bridge_to_lt9611(struct drm_bridge *bridge)
+{
+ return container_of(bridge, struct lt9611, bridge);
+}
+
+static struct lt9611 *connector_to_lt9611(struct drm_connector *connector)
+{
+ return container_of(connector, struct lt9611, connector);
+}
+
+static int lt9611_mipi_input_analog(st
Re: [PATCH] drm/of: Consider the state in which the ep is disabled
Hi heiko
在 2020/7/6 17:47, Heiko Stübner 写道:
Hi Sandy,
Am Montag, 6. Juli 2020, 09:59:44 CEST schrieb Sandy Huang:
don't mask possible_crtcs if remote-point is disabled.
Signed-off-by: Sandy Huang
---
drivers/gpu/drm/drm_of.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c
index fdb05fbf72a0..f5f250435add 100644
--- a/drivers/gpu/drm/drm_of.c
+++ b/drivers/gpu/drm/drm_of.c
@@ -66,6 +66,11 @@ uint32_t drm_of_find_possible_crtcs(struct drm_device *dev,
uint32_t possible_crtcs = 0;
for_each_endpoint_of_node(port, ep) {
+ if (!of_device_is_available(ep)) {
+ of_node_put(ep);
You'd only need the of_node_put here, if you were exiting the loop.
With the "continue" below, the next iteration of for_each_endpoint_of_node
will do the put on "ep"
Just as we communicate on the google talk, the v2 patch will delete
of_node_put(ep) and leave continue, thanks.
Heiko
+ continue;
+ }
+
remote_port = of_graph_get_remote_port(ep);
if (!remote_port) {
of_node_put(ep);
--
Best Regard
黄家钗
Sandy Huang
Addr: 福州市鼓楼区铜盘路软件大道89号福州软件园A区21号楼(350003)
No. 21 Building, A District, No.89,software Boulevard Fuzhou,Fujian,PRC
Tel：+86 0591-87884919 8690
E-mail：h...@rock-chips.com
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 11/20] Documentation: leds/ledtrig-transient: eliminate duplicated word
Drop the doubled word "for". Signed-off-by: Randy Dunlap Cc: Jonathan Corbet Cc: linux-...@vger.kernel.org Cc: Jacek Anaszewski Cc: Pavel Machek Cc: Dan Murphy Cc: linux-l...@vger.kernel.org --- Documentation/leds/ledtrig-transient.rst |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-next-20200701.orig/Documentation/leds/ledtrig-transient.rst +++ linux-next-20200701/Documentation/leds/ledtrig-transient.rst @@ -157,7 +157,7 @@ repeat the following step as needed:: echo 1 > activate - start timer = duration to run once echo none > trigger -This trigger is intended to be used for for the following example use cases: +This trigger is intended to be used for the following example use cases: - Control of vibrate (phones, tablets etc.) hardware by user space app. - Use of LED by user space app as activity indicator. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 1/9] soc: mediatek: cmdq: add address shift in jump
Add address shift when compose jump instruction to compatible with 35bit format. Change since v1: - Rename cmdq_mbox_shift() to cmdq_get_shift_pa(). Signed-off-by: Dennis YC Hsieh --- drivers/soc/mediatek/mtk-cmdq-helper.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c b/drivers/soc/mediatek/mtk-cmdq-helper.c index dc644cfb6419..9faf78fbed3a 100644 --- a/drivers/soc/mediatek/mtk-cmdq-helper.c +++ b/drivers/soc/mediatek/mtk-cmdq-helper.c @@ -329,7 +329,8 @@ int cmdq_pkt_finalize(struct cmdq_pkt *pkt) /* JUMP to end */ inst.op = CMDQ_CODE_JUMP; - inst.value = CMDQ_JUMP_PASS; + inst.value = CMDQ_JUMP_PASS >> + cmdq_get_shift_pa(((struct cmdq_client *)pkt->cl)->chan); err = cmdq_pkt_append_command(pkt, inst); return err; -- 1.7.9.5 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 00/20] Documentation: eliminate duplicated words
Drop doubled words in various parts of Documentation/. Cc: Jonathan Corbet Cc: linux-...@vger.kernel.org Cc: linux...@vger.kernel.org Cc: Mike Rapoport Cc: Jens Axboe Cc: linux-bl...@vger.kernel.org Cc: Jason Wessel Cc: Daniel Thompson Cc: Douglas Anderson Cc: kgdb-bugrep...@lists.sourceforge.net Cc: Wu Hao Cc: linux-f...@vger.kernel.org Cc: James (Qian) Wang Cc: Liviu Dudau Cc: Mihail Atanassov Cc: Mali DP Maintainers Cc: David Airlie Cc: Daniel Vetter Cc: dri-devel@lists.freedesktop.org Cc: Srinivas Pandruvada Cc: Jiri Kosina Cc: linux-in...@vger.kernel.org Cc: Wolfram Sang Cc: linux-...@vger.kernel.org Cc: Masahiro Yamada Cc: Michal Marek Cc: linux-kbu...@vger.kernel.org Cc: Jacek Anaszewski Cc: Pavel Machek Cc: Dan Murphy Cc: linux-l...@vger.kernel.org Cc: Dan Williams Cc: Paul Cercueil Cc: Thomas Bogendoerfer Cc: linux-m...@vger.kernel.org Cc: Derek Kiernan Cc: Dragan Cvetic Cc: Michael Ellerman Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: linuxppc-...@lists.ozlabs.org Cc: Tony Krowiak Cc: Pierre Morel Cc: Halil Pasic Cc: linux-s...@vger.kernel.org Cc: Matthew Wilcox Cc: Hannes Reinecke Cc: linux-s...@vger.kernel.org Cc: "James E.J. Bottomley" Cc: "Martin K. Petersen" Cc: James Bottomley Cc: Jarkko Sakkinen Cc: Mimi Zohar Cc: linux-integr...@vger.kernel.org Cc: keyri...@vger.kernel.org Cc: Paolo Bonzini Cc: k...@vger.kernel.org Cc: Andrew Morton Documentation/admin-guide/mm/numaperf.rst |2 +- Documentation/block/pr.rst|2 +- Documentation/core-api/printk-basics.rst |2 +- Documentation/dev-tools/kgdb.rst |2 +- Documentation/fpga/dfl.rst|2 +- Documentation/gpu/drm-uapi.rst|2 +- Documentation/gpu/komeda-kms.rst |2 +- Documentation/hid/intel-ish-hid.rst |2 +- Documentation/i2c/upgrading-clients.rst |2 +- Documentation/kbuild/kconfig-language.rst |2 +- Documentation/leds/ledtrig-transient.rst |2 +- Documentation/maintainer/maintainer-entry-profile.rst |2 +- Documentation/mips/ingenic-tcu.rst|2 +- Documentation/misc-devices/xilinx_sdfec.rst |2 +- Documentation/powerpc/vas-api.rst |2 +- Documentation/s390/vfio-ap.rst|2 +- Documentation/scsi/advansys.rst |2 +- Documentation/security/keys/trusted-encrypted.rst |2 +- Documentation/virt/kvm/api.rst|2 +- Documentation/vm/memory-model.rst |2 +- 20 files changed, 20 insertions(+), 20 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 05/20] Documentation: fpga: eliminate duplicated word
Drop the doubled word "this". Signed-off-by: Randy Dunlap Cc: Jonathan Corbet Cc: linux-...@vger.kernel.org Cc: Wu Hao Cc: linux-f...@vger.kernel.org --- Documentation/fpga/dfl.rst |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-next-20200701.orig/Documentation/fpga/dfl.rst +++ linux-next-20200701/Documentation/fpga/dfl.rst @@ -8,7 +8,7 @@ Authors: - Xiao Guangrong - Wu Hao -The Device Feature List (DFL) FPGA framework (and drivers according to this +The Device Feature List (DFL) FPGA framework (and drivers according to this framework) hides the very details of low layer hardwares and provides unified interfaces to userspace. Applications could use these interfaces to configure, enumerate, open and access FPGA accelerators on platforms which ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/4] drm: mipi-dsi: Convert logging to drm_* functions.
Convert logging errors from dev_err() to drm_err().
Signed-off-by: Suraj Upadhyay
---
drivers/gpu/drm/drm_mipi_dsi.c | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c
index 07102d8da58f..5dd475e82995 100644
--- a/drivers/gpu/drm/drm_mipi_dsi.c
+++ b/drivers/gpu/drm/drm_mipi_dsi.c
@@ -34,6 +34,7 @@
#include
#include
+#include
#include
/**
@@ -155,19 +156,18 @@ static int mipi_dsi_device_add(struct mipi_dsi_device
*dsi)
static struct mipi_dsi_device *
of_mipi_dsi_device_add(struct mipi_dsi_host *host, struct device_node *node)
{
- struct device *dev = host->dev;
struct mipi_dsi_device_info info = { };
int ret;
u32 reg;
if (of_modalias_node(node, info.type, sizeof(info.type)) < 0) {
- dev_err(dev, "modalias failure on %pOF\n", node);
+ drm_err(host, "modalias failure on %pOF\n", node);
return ERR_PTR(-EINVAL);
}
ret = of_property_read_u32(node, "reg", ®);
if (ret) {
- dev_err(dev, "device node %pOF has no valid reg property: %d\n",
+ drm_err(host, "device node %pOF has no valid reg property:
%d\n",
node, ret);
return ERR_PTR(-EINVAL);
}
@@ -202,22 +202,21 @@ mipi_dsi_device_register_full(struct mipi_dsi_host *host,
const struct mipi_dsi_device_info *info)
{
struct mipi_dsi_device *dsi;
- struct device *dev = host->dev;
int ret;
if (!info) {
- dev_err(dev, "invalid mipi_dsi_device_info pointer\n");
+ drm_err(host, "invalid mipi_dsi_device_info pointer\n");
return ERR_PTR(-EINVAL);
}
if (info->channel > 3) {
- dev_err(dev, "invalid virtual channel: %u\n", info->channel);
+ drm_err(host, "invalid virtual channel: %u\n", info->channel);
return ERR_PTR(-EINVAL);
}
dsi = mipi_dsi_device_alloc(host);
if (IS_ERR(dsi)) {
- dev_err(dev, "failed to allocate DSI device %ld\n",
+ drm_err(host, "failed to allocate DSI device %ld\n",
PTR_ERR(dsi));
return dsi;
}
@@ -228,7 +227,7 @@ mipi_dsi_device_register_full(struct mipi_dsi_host *host,
ret = mipi_dsi_device_add(dsi);
if (ret) {
- dev_err(dev, "failed to add DSI device %d\n", ret);
+ drm_err(host, "failed to add DSI device %d\n", ret);
kfree(dsi);
return ERR_PTR(ret);
}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 3/9] soc: mediatek: cmdq: add write_s_mask function
add write_s_mask function in cmdq helper functions which
writes value contains in internal register to address
with mask and large dma access support.
Signed-off-by: Dennis YC Hsieh
---
drivers/soc/mediatek/mtk-cmdq-helper.c | 23 +++
include/linux/mailbox/mtk-cmdq-mailbox.h |1 +
include/linux/soc/mediatek/mtk-cmdq.h| 18 ++
3 files changed, 42 insertions(+)
diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c
b/drivers/soc/mediatek/mtk-cmdq-helper.c
index 880349b3f16c..550e9e7e3ff2 100644
--- a/drivers/soc/mediatek/mtk-cmdq-helper.c
+++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
@@ -242,6 +242,29 @@ int cmdq_pkt_write_s(struct cmdq_pkt *pkt, u16
high_addr_reg_idx,
}
EXPORT_SYMBOL(cmdq_pkt_write_s);
+int cmdq_pkt_write_s_mask(struct cmdq_pkt *pkt, u16 high_addr_reg_idx,
+ u16 addr_low, u16 src_reg_idx, u32 mask)
+{
+ struct cmdq_instruction inst = {};
+ int err;
+
+ inst.op = CMDQ_CODE_MASK;
+ inst.mask = ~mask;
+ err = cmdq_pkt_append_command(pkt, inst);
+ if (err < 0)
+ return err;
+
+ inst.mask = 0;
+ inst.op = CMDQ_CODE_WRITE_S_MASK;
+ inst.src_t = CMDQ_REG_TYPE;
+ inst.sop = high_addr_reg_idx;
+ inst.offset = addr_low;
+ inst.src_reg = src_reg_idx;
+
+ return cmdq_pkt_append_command(pkt, inst);
+}
+EXPORT_SYMBOL(cmdq_pkt_write_s_mask);
+
int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event)
{
struct cmdq_instruction inst = { {0} };
diff --git a/include/linux/mailbox/mtk-cmdq-mailbox.h
b/include/linux/mailbox/mtk-cmdq-mailbox.h
index 1f76cfedb16d..90d1d8e64412 100644
--- a/include/linux/mailbox/mtk-cmdq-mailbox.h
+++ b/include/linux/mailbox/mtk-cmdq-mailbox.h
@@ -61,6 +61,7 @@ enum cmdq_code {
CMDQ_CODE_WFE = 0x20,
CMDQ_CODE_EOC = 0x40,
CMDQ_CODE_WRITE_S = 0x90,
+ CMDQ_CODE_WRITE_S_MASK = 0x91,
CMDQ_CODE_LOGIC = 0xa0,
};
diff --git a/include/linux/soc/mediatek/mtk-cmdq.h
b/include/linux/soc/mediatek/mtk-cmdq.h
index 9b0c57a0063d..53230341bf94 100644
--- a/include/linux/soc/mediatek/mtk-cmdq.h
+++ b/include/linux/soc/mediatek/mtk-cmdq.h
@@ -122,6 +122,24 @@ int cmdq_pkt_write_s(struct cmdq_pkt *pkt, u16
high_addr_reg_idx,
u16 addr_low, u16 src_reg_idx);
/**
+ * cmdq_pkt_write_s_mask() - append write_s with mask command to the CMDQ
packet
+ * @pkt: the CMDQ packet
+ * @high_addr_reg_idx: internal register ID which contains high address of pa
+ * @addr_low: low address of pa
+ * @src_reg_idx: the CMDQ internal register ID which cache source value
+ * @mask: the specified target address mask, use U32_MAX if no need
+ *
+ * Return: 0 for success; else the error code is returned
+ *
+ * Support write value to physical address without subsys. Use CMDQ_ADDR_HIGH()
+ * to get high address and call cmdq_pkt_assign() to assign value into internal
+ * reg. Also use CMDQ_ADDR_LOW() to get low address for addr_low parameter when
+ * call to this function.
+ */
+int cmdq_pkt_write_s_mask(struct cmdq_pkt *pkt, u16 high_addr_reg_idx,
+ u16 addr_low, u16 src_reg_idx, u32 mask);
+
+/**
* cmdq_pkt_wfe() - append wait for event command to the CMDQ packet
* @pkt: the CMDQ packet
* @event: the desired event type to "wait and CLEAR"
--
1.7.9.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7 2/2] display/drm/bridge: TC358775 DSI/LVDS driver
Andrzej, Please suggest. In general it should be in the reverse-order RESX then STBY, But As per the spec Datasheet Power off sequence is this Page 149, Section Power Supply On and Off Sequence regulators STBY RESX https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=&ved=2ahUKEwiBmeWb2brqAhXO7HMBHZgaCTUQFjACegQIBxAB&url=https%3A%2F%2Fdownload.t-firefly.com%2Fproduct%2FRK3399%2FDocs%2FChip%2520Specifications%2FTC358774XBG_75XBG_V1%25204nm.pdf&usg=AOvVaw2kBuPv8FaZBNynGWCQHEfc Regarding data-lanes -data-lanes value does appear later from the mdp->dsi0 tree -We need to pick dynamically data-lanes of the dsi set, based on this we need to set in the bridge. Otherwise we are already setting in dsi0 ports as <0 1 2 3> , again we need to set it in the bridge tree. - There is no helper function to get the data-lanes of the DSI On Tue, Jul 7, 2020 at 12:15 PM Andrzej Hajda wrote: > > On 04.07.2020 11:24, Vinay Simha BN wrote: > > This driver is tested with two panels individually with Apq8016-IFC6309 > board > > > https://protect2.fireeye.com/url?k=fe87a8ec-a3e0ecca-fe8623a3-0cc47a31384a-ffbc547df1141490&q=1&u=https%3A%2F%2Fwww.inforcecomputing.com%2Fproducts%2Fsingle-board-computers-sbc%2Fqualcomm-snapdragon-410-inforce-6309-micro-sbc > > > > 1. 1366x768@60 auo,b101xtn01 data-mapping = "jeida-24" > > 2. 800x480@60 innolux,at070tn92 data-mapping = "vesa-24" > > > > - added SPDX identifier license > > - updated alphabetic order of headers > > - replaced u32 instead of uint32_t > > - magic number to macros for CLRSI and mux registers > > - mdelay to usleep_range > > - added bus_formats > > - removed drm_connector_status > > - regulator enable and disable with proper orders and delays > >as per the spec > > - devm_drm_panel_bridge_add method used instead of panel > >description modified > > - dual port implemented > > - panel->connector_type removed > > - ~vsdelay dynamic value set based on the > >calculation of dsi speed, output speed, blanking > > - help modified > > - display_timings naming local variables > > - check for bus_formats unsupported > > - error handling enpoint data-lanes > > - Kconfig proper indentation > > - GENMASK and FIELD_PREP used > > - bus_formats handeld in mode_valid > > - MODE_CLOCK_HIGH handled properly > > - len initialized > > - static function for mode_valid > > > > Signed-off-by: Vinay Simha BN > > --- > > v1: > > Initial version > > > > v2: > > * Andrzej Hajda review comments incorporated > >SPDX identifier > >development debug removed > >alphabetic order headers > >u32 instead of unit32_t > >magic numbers to macros for CLRSI and mux registers > >ignored return value > > > > * Laurent Pinchart review comments incorporated > >mdelay to usleep_range > >bus_formats added > > > > v3: > > * Andrzej Hajda review comments incorporated > >drm_connector_status removed > >u32 rev removed and local variabl is used > >regulator enable disable with proper orders and delays > >as per the spec > >devm_drm_panel_bridge_add method used instead of panel > >description modified > >dual port implemented > > > > v4: > > * Sam Ravnborg review comments incorporated > >panel->connector_type removed > > > > * Reported-by: kernel test robot > >parse_dt to static function > >removed the if (endpoint), since data-lanes has to be > >present for dsi dts ports > > > > v5: > >~vsdelay dynamic value set based on the > >calculation of dsi speed, output speed, blanking > > > > v6: > > * Sam Ravnborg review comments incorporated > >help modified > >display_timings naming local variables > >check for bus_formats unsupported > >error handling enpoint data-lanes > > > > v7: > > * Sam Ravnborg review comments incorporated > >Kconfig proper indentation > >GENMASK and FIELD_PREP used > >bus_formats handeld in mode_valid > >MODE_CLOCK_HIGH handled properly > > > > * Reported-by: kernel test robot > >len initialized > >static function for mode_valid > > --- > > drivers/gpu/drm/bridge/Kconfig| 10 + > > drivers/gpu/drm/bridge/Makefile | 1 + > > drivers/gpu/drm/bridge/tc358775.c | 757 ++ > > 3 files changed, 768 insertions(+) > > create mode 100644 drivers/gpu/drm/bridge/tc358775.c > > > > diff --git a/drivers/gpu/drm/bridge/Kconfig > b/drivers/gpu/drm/bridge/Kconfig > > index 43271c21d3fc..25c3097c4003 100644 > > --- a/drivers/gpu/drm/bridge/Kconfig > > +++ b/drivers/gpu/drm/bridge/Kconfig > > @@ -181,6 +181,16 @@ config DRM_TOSHIBA_TC358768 > > help > > Toshiba TC358768AXBG/TC358778XBG DSI bridge chip driver. > > > > +config DRM_TOSHIBA_TC358775 > > + tristate "Toshiba TC358775 DSI/LVDS bridge" > > + depends on OF > > + select DRM_KMS_HELPER > > + select REGMAP_I2C > > + select DRM_PANEL > > + select DRM_MIPI_DSI > > + help > > + Toshiba TC358775 DSI/LVDS bridge chip driver. > > + >
[PATCH 14/20] Documentation: misc/xilinx_sdfec: eliminate duplicated word
Drop the doubled word "the". Signed-off-by: Randy Dunlap Cc: Jonathan Corbet Cc: linux-...@vger.kernel.org Cc: Derek Kiernan Cc: Dragan Cvetic --- Documentation/misc-devices/xilinx_sdfec.rst |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-next-20200701.orig/Documentation/misc-devices/xilinx_sdfec.rst +++ linux-next-20200701/Documentation/misc-devices/xilinx_sdfec.rst @@ -78,7 +78,7 @@ application interfaces: - open: Implements restriction that only a single file descriptor can be open per SD-FEC instance at any time - release: Allows another file descriptor to be open, that is after current file descriptor is closed - poll: Provides a method to monitor for SD-FEC Error events - - unlocked_ioctl: Provides the the following ioctl commands that allows the application configure the SD-FEC core: + - unlocked_ioctl: Provides the following ioctl commands that allows the application configure the SD-FEC core: - :c:macro:`XSDFEC_START_DEV` - :c:macro:`XSDFEC_STOP_DEV` ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 13/20] Documentation: mips/ingenic-tcu: eliminate duplicated word
Drop the doubled word "to". Signed-off-by: Randy Dunlap Cc: Jonathan Corbet Cc: linux-...@vger.kernel.org Cc: Paul Cercueil Cc: Thomas Bogendoerfer Cc: linux-m...@vger.kernel.org --- Documentation/mips/ingenic-tcu.rst |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-next-20200701.orig/Documentation/mips/ingenic-tcu.rst +++ linux-next-20200701/Documentation/mips/ingenic-tcu.rst @@ -5,7 +5,7 @@ Ingenic JZ47xx SoCs Timer/Counter Unit h === The Timer/Counter Unit (TCU) in Ingenic JZ47xx SoCs is a multi-function -hardware block. It features up to to eight channels, that can be used as +hardware block. It features up to eight channels, that can be used as counters, timers, or PWM. - JZ4725B, JZ4750, JZ4755 only have six TCU channels. The other SoCs all ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 12/20] Documentation: maintainer-entry-profile: eliminate duplicated word
Drop the doubled word "have". Signed-off-by: Randy Dunlap Cc: Jonathan Corbet Cc: linux-...@vger.kernel.org Cc: Dan Williams --- Documentation/maintainer/maintainer-entry-profile.rst |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-next-20200701.orig/Documentation/maintainer/maintainer-entry-profile.rst +++ linux-next-20200701/Documentation/maintainer/maintainer-entry-profile.rst @@ -31,7 +31,7 @@ Example questions to consider: - What branch should contributors submit against? - Links to any other Maintainer Entry Profiles? For example a device-driver may point to an entry for its parent subsystem. This makes - the contributor aware of obligations a maintainer may have have for + the contributor aware of obligations a maintainer may have for other maintainers in the submission chain. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 10/20] Documentation: kbuild/kconfig-language: eliminate duplicated word
Drop the doubled word "the". Signed-off-by: Randy Dunlap Cc: Jonathan Corbet Cc: linux-...@vger.kernel.org Cc: Masahiro Yamada Cc: Michal Marek Cc: linux-kbu...@vger.kernel.org --- Documentation/kbuild/kconfig-language.rst |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-next-20200701.orig/Documentation/kbuild/kconfig-language.rst +++ linux-next-20200701/Documentation/kbuild/kconfig-language.rst @@ -681,7 +681,7 @@ translate Kconfig logic into boolean for find dead code / features (always inactive), 114 dead features were found in Linux using this methodology [1]_ (Section 8: Threats to validity). -Confirming this could prove useful as Kconfig stands as one of the the leading +Confirming this could prove useful as Kconfig stands as one of the leading industrial variability modeling languages [1]_ [2]_. Its study would help evaluate practical uses of such languages, their use was only theoretical and real world requirements were not well understood. As it stands though ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 0/9] drm/vc4: Turn the TXP into a CRTC
On Mon, Jul 06, 2020 at 05:51:29PM -0700, Eric Anholt wrote: > On Tue, Jun 30, 2020 at 1:25 AM Maxime Ripard wrote: > > > > Hi Eric, > > > > On Thu, Jun 11, 2020 at 03:36:45PM +0200, Maxime Ripard wrote: > > > Hi, > > > > > > This is another part of the rpi4 HDMI series that got promoted to a > > > series of its own to try to reduce the main one. > > > > > > This rework is needed since the bcm2711 used in the rpi4 has a more > > > complex routing in the HVS that doesn't allow to use a fairly simple > > > mapping like what was used before. > > > > > > Since that mapping affects both the pixelvalves and the TXP, turning the > > > TXP into a CRTC just like pixelvalves are allows to deal with the > > > mapping in the CRTC states, which turns out to be pretty convenient. > > > > > > Let me know what you think, > > > Maxime > > > > > > Changes from v3: > > > - Stripped the patches out of the main HDMI series > > > - Change the bind order of the HVS to avoid a compatible check > > > - Added Eric's tags > > > - Rebased on top of drm-misc-next > > > > > > Maxime Ripard (9): > > > drm/vc4: Reorder the bind order of the devices > > > drm/vc4: crtc: Move HVS setup code to the HVS driver > > > > Could you review those two patches? You haven't reviewed them yet and > > it's holding back the rest of the patches. > > LKML email workflow is the worst, the patches never came through to me > so I didn't see them until you linked me the patchwork. Patch 2, > commit message should say "We'll need the HVS to be bound before the > TXP", but other than that, r-b. I've fixed the commit message and applied, thanks (and sorry for the troubles). Maxime signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 7/9] soc: mediatek: cmdq: add jump function
Add jump function so that client can jump to any address which
contains instruction.
Signed-off-by: Dennis YC Hsieh
---
drivers/soc/mediatek/mtk-cmdq-helper.c | 13 +
include/linux/soc/mediatek/mtk-cmdq.h | 11 +++
2 files changed, 24 insertions(+)
diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c
b/drivers/soc/mediatek/mtk-cmdq-helper.c
index b6e25f216605..d55dc3296105 100644
--- a/drivers/soc/mediatek/mtk-cmdq-helper.c
+++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
@@ -13,6 +13,7 @@
#define CMDQ_POLL_ENABLE_MASK BIT(0)
#define CMDQ_EOC_IRQ_ENBIT(0)
#define CMDQ_REG_TYPE 1
+#define CMDQ_JUMP_RELATIVE 1
struct cmdq_instruction {
union {
@@ -407,6 +408,18 @@ int cmdq_pkt_assign(struct cmdq_pkt *pkt, u16 reg_idx, u32
value)
}
EXPORT_SYMBOL(cmdq_pkt_assign);
+int cmdq_pkt_jump(struct cmdq_pkt *pkt, dma_addr_t addr)
+{
+ struct cmdq_instruction inst = {};
+
+ inst.op = CMDQ_CODE_JUMP;
+ inst.offset = CMDQ_JUMP_RELATIVE;
+ inst.value = addr >>
+ cmdq_get_shift_pa(((struct cmdq_client *)pkt->cl)->chan);
+ return cmdq_pkt_append_command(pkt, inst);
+}
+EXPORT_SYMBOL(cmdq_pkt_jump);
+
int cmdq_pkt_finalize(struct cmdq_pkt *pkt)
{
struct cmdq_instruction inst = { {0} };
diff --git a/include/linux/soc/mediatek/mtk-cmdq.h
b/include/linux/soc/mediatek/mtk-cmdq.h
index d9390d76ee14..34354e952f60 100644
--- a/include/linux/soc/mediatek/mtk-cmdq.h
+++ b/include/linux/soc/mediatek/mtk-cmdq.h
@@ -253,6 +253,17 @@ int cmdq_pkt_poll_mask(struct cmdq_pkt *pkt, u8 subsys,
int cmdq_pkt_assign(struct cmdq_pkt *pkt, u16 reg_idx, u32 value);
/**
+ * cmdq_pkt_jump() - Append jump command to the CMDQ packet, ask GCE
+ * to execute an instruction that change current thread PC to
+ * a physical address which should contains more instruction.
+ * @pkt:the CMDQ packet
+ * @addr: physical address of target instruction buffer
+ *
+ * Return: 0 for success; else the error code is returned
+ */
+int cmdq_pkt_jump(struct cmdq_pkt *pkt, dma_addr_t addr);
+
+/**
* cmdq_pkt_finalize() - Append EOC and jump command to pkt.
* @pkt: the CMDQ packet
*
--
1.7.9.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/4] drm: fb-helper: Convert logging to drm_* functions.
Change logging information from dev_info() to drm_info(). Signed-off-by: Suraj Upadhyay --- drivers/gpu/drm/drm_fb_helper.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c index 5609e164805f..88146f7245c5 100644 --- a/drivers/gpu/drm/drm_fb_helper.c +++ b/drivers/gpu/drm/drm_fb_helper.c @@ -1819,7 +1819,7 @@ __drm_fb_helper_initial_config_and_unlock(struct drm_fb_helper *fb_helper, if (ret < 0) return ret; - dev_info(dev->dev, "fb%d: %s frame buffer device\n", + drm_info(dev, "fb%d: %s frame buffer device\n", info->node, info->fix.id); mutex_lock(&kernel_fb_helper_lock); -- 2.17.1 signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 4/9] soc: mediatek: cmdq: add read_s function
Add read_s function in cmdq helper functions which support read value from
register or dma physical address into gce internal register.
Signed-off-by: Dennis YC Hsieh
---
drivers/soc/mediatek/mtk-cmdq-helper.c | 15 +++
include/linux/mailbox/mtk-cmdq-mailbox.h |1 +
include/linux/soc/mediatek/mtk-cmdq.h| 12
3 files changed, 28 insertions(+)
diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c
b/drivers/soc/mediatek/mtk-cmdq-helper.c
index 550e9e7e3ff2..ed9f5e63c195 100644
--- a/drivers/soc/mediatek/mtk-cmdq-helper.c
+++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
@@ -227,6 +227,21 @@ int cmdq_pkt_write_mask(struct cmdq_pkt *pkt, u8 subsys,
}
EXPORT_SYMBOL(cmdq_pkt_write_mask);
+int cmdq_pkt_read_s(struct cmdq_pkt *pkt, u16 high_addr_reg_idx, u16 addr_low,
+ u16 reg_idx)
+{
+ struct cmdq_instruction inst = {};
+
+ inst.op = CMDQ_CODE_READ_S;
+ inst.dst_t = CMDQ_REG_TYPE;
+ inst.sop = high_addr_reg_idx;
+ inst.reg_dst = reg_idx;
+ inst.src_reg = addr_low;
+
+ return cmdq_pkt_append_command(pkt, inst);
+}
+EXPORT_SYMBOL(cmdq_pkt_read_s);
+
int cmdq_pkt_write_s(struct cmdq_pkt *pkt, u16 high_addr_reg_idx,
u16 addr_low, u16 src_reg_idx)
{
diff --git a/include/linux/mailbox/mtk-cmdq-mailbox.h
b/include/linux/mailbox/mtk-cmdq-mailbox.h
index 90d1d8e64412..efbd8a9eb2d1 100644
--- a/include/linux/mailbox/mtk-cmdq-mailbox.h
+++ b/include/linux/mailbox/mtk-cmdq-mailbox.h
@@ -60,6 +60,7 @@ enum cmdq_code {
CMDQ_CODE_JUMP = 0x10,
CMDQ_CODE_WFE = 0x20,
CMDQ_CODE_EOC = 0x40,
+ CMDQ_CODE_READ_S = 0x80,
CMDQ_CODE_WRITE_S = 0x90,
CMDQ_CODE_WRITE_S_MASK = 0x91,
CMDQ_CODE_LOGIC = 0xa0,
diff --git a/include/linux/soc/mediatek/mtk-cmdq.h
b/include/linux/soc/mediatek/mtk-cmdq.h
index 53230341bf94..cd7ec714344e 100644
--- a/include/linux/soc/mediatek/mtk-cmdq.h
+++ b/include/linux/soc/mediatek/mtk-cmdq.h
@@ -104,6 +104,18 @@ struct cmdq_client *cmdq_mbox_create(struct device *dev,
int index,
int cmdq_pkt_write_mask(struct cmdq_pkt *pkt, u8 subsys,
u16 offset, u32 value, u32 mask);
+/*
+ * cmdq_pkt_read_s() - append read_s command to the CMDQ packet
+ * @pkt: the CMDQ packet
+ * @high_addr_reg_idx: internal register ID which contains high address of pa
+ * @addr_low: low address of pa
+ * @reg_idx: the CMDQ internal register ID to cache read data
+ *
+ * Return: 0 for success; else the error code is returned
+ */
+int cmdq_pkt_read_s(struct cmdq_pkt *pkt, u16 high_addr_reg_idx, u16 addr_low,
+ u16 reg_idx);
+
/**
* cmdq_pkt_write_s() - append write_s command to the CMDQ packet
* @pkt: the CMDQ packet
--
1.7.9.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/2] drm: drm_fourcc: add NV20 and NV30 YUV formats【请注意，邮件由linux-rockchip-bounces+sandy.huang=rock-chips....@lists.infradead.org代发】
在 2020/7/7 6:30, Jonas Karlman 写道:
DRM_FORMAT_NV20 and DRM_FORMAT_NV30 formats is the 2x1 and non-subsampled
variant of NV15, a 10-bit 2-plane YUV format that has no padding between
components. Instead, luminance and chrominance samples are grouped into 4s
so that each group is packed into an integer number of bytes:
= UVUV = 4 * 10 bits = 40 bits = 5 bytes
The '20' and '30' suffix refers to the optimum effective bits per pixel
which is achieved when the total number of luminance samples is a multiple
of 4.
V2: Added NV30 format
Signed-off-by: Jonas Karlman
---
drivers/gpu/drm/drm_fourcc.c | 8
include/uapi/drm/drm_fourcc.h | 2 ++
2 files changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index 722c7ebe4e88..2daf8a304b53 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -278,6 +278,14 @@ const struct drm_format_info *__drm_format_info(u32 format)
.num_planes = 2, .char_per_block = { 5, 5, 0 },
.block_w = { 4, 2, 0 }, .block_h = { 1, 1, 0 }, .hsub = 2,
.vsub = 2, .is_yuv = true },
+ { .format = DRM_FORMAT_NV20,.depth = 0,
+ .num_planes = 2, .char_per_block = { 5, 5, 0 },
+ .block_w = { 4, 2, 0 }, .block_h = { 1, 1, 0 }, .hsub = 2,
+ .vsub = 1, .is_yuv = true },
+ { .format = DRM_FORMAT_NV30,.depth = 0,
+ .num_planes = 2, .char_per_block = { 5, 5, 0 },
+ .block_w = { 4, 2, 0 }, .block_h = { 1, 1, 0 }, .hsub = 1,
+ .vsub = 1, .is_yuv = true },
{ .format = DRM_FORMAT_Q410,.depth = 0,
.num_planes = 3, .char_per_block = { 2, 2, 2 },
.block_w = { 1, 1, 1 }, .block_h = { 1, 1, 1 }, .hsub = 0,
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index cbf92fdf2712..c8695673295c 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -242,6 +242,8 @@ extern "C" {
* index 1 = Cr:Cb plane, [39:0] Cr1:Cb1:Cr0:Cb0 little endian
*/
#define DRM_FORMAT_NV15 fourcc_code('N', 'V', '1', '5') /* 2x2
subsampled Cr:Cb plane */
+#define DRM_FORMAT_NV20fourcc_code('N', 'V', '2', '0') /* 2x1
subsampled Cr:Cb plane */
+#define DRM_FORMAT_NV30fourcc_code('N', 'V', '3', '0') /*
non-subsampled Cr:Cb plane */
/*
* 2 plane YCbCr MSB aligned
Reviewed-by: Sandy Huang
--
Best Regard
黄家钗
Sandy Huang
Addr: 福州市鼓楼区铜盘路软件大道89号福州软件园A区21号楼(350003)
No. 21 Building, A District, No.89,software Boulevard Fuzhou,Fujian,PRC
Tel：+86 0591-87884919 8690
E-mail：h...@rock-chips.com
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 04/20] Documentation: kgdb: eliminate duplicated word
Drop the doubled word "driver". Signed-off-by: Randy Dunlap Cc: Jonathan Corbet Cc: linux-...@vger.kernel.org Cc: Jason Wessel Cc: Daniel Thompson Cc: Douglas Anderson Cc: kgdb-bugrep...@lists.sourceforge.net --- Documentation/dev-tools/kgdb.rst |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-next-20200701.orig/Documentation/dev-tools/kgdb.rst +++ linux-next-20200701/Documentation/dev-tools/kgdb.rst @@ -872,7 +872,7 @@ The kgdboc driver contains logic to conf attached keyboard. The keyboard infrastructure is only compiled into the kernel when ``CONFIG_KDB_KEYBOARD=y`` is set in the kernel configuration. -The core polled keyboard driver driver for PS/2 type keyboards is in +The core polled keyboard driver for PS/2 type keyboards is in ``drivers/char/kdb_keyboard.c``. This driver is hooked into the debug core when kgdboc populates the callback in the array called :c:type:`kdb_poll_funcs[]`. The :c:func:`kdb_get_kbd_char` is the top-level ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/panel-simple: Fix inverted V/H SYNC for Frida FRD350H54004 panel
The FRD350H54004 panel was marked as having active-high VSYNC and HSYNC
signals, which sorts-of worked, but resulted in the picture fading out
under certain circumstances.
Fix this issue by marking VSYNC and HSYNC signals active-low.
Fixes: 7b6bd8433609 ("drm/panel: simple: Add support for the Frida FRD350H54004
panel")
Cc: sta...@vger.kernel.org # v5.5
Signed-off-by: Paul Cercueil
---
drivers/gpu/drm/panel/panel-simple.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 5178f87d6574..1188d191076b 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1703,7 +1703,7 @@ static const struct drm_display_mode
frida_frd350h54004_mode = {
.vsync_end = 240 + 2 + 6,
.vtotal = 240 + 2 + 6 + 2,
.vrefresh = 60,
- .flags = DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC,
+ .flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC,
};
static const struct panel_desc frida_frd350h54004 = {
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 01/20] Documentation: numaperf: eliminate duplicated word
Drop the duplicated word "not". Signed-off-by: Randy Dunlap Cc: Jonathan Corbet Cc: linux-...@vger.kernel.org Cc: linux...@vger.kernel.org Cc: Mike Rapoport --- Documentation/admin-guide/mm/numaperf.rst |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-5.8-rc3.orig/Documentation/admin-guide/mm/numaperf.rst +++ linux-5.8-rc3/Documentation/admin-guide/mm/numaperf.rst @@ -129,7 +129,7 @@ will create the following directory:: /sys/devices/system/node/nodeX/memory_side_cache/ -If that directory is not present, the system either does not not provide +If that directory is not present, the system either does not provide a memory-side cache, or that information is not accessible to the kernel. The attributes for each level of cache is provided under its cache ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 6/9] soc: mediatek: cmdq: add write_s_mask value function
add write_s_mask_value function in cmdq helper functions which
writes a constant value to address with mask and large dma
access support.
Signed-off-by: Dennis YC Hsieh
---
drivers/soc/mediatek/mtk-cmdq-helper.c | 21 +
include/linux/soc/mediatek/mtk-cmdq.h | 15 +++
2 files changed, 36 insertions(+)
diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c
b/drivers/soc/mediatek/mtk-cmdq-helper.c
index 4e86b65815fc..b6e25f216605 100644
--- a/drivers/soc/mediatek/mtk-cmdq-helper.c
+++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
@@ -294,6 +294,27 @@ int cmdq_pkt_write_s_value(struct cmdq_pkt *pkt, u8
high_addr_reg_idx,
}
EXPORT_SYMBOL(cmdq_pkt_write_s_value);
+int cmdq_pkt_write_s_mask_value(struct cmdq_pkt *pkt, u8 high_addr_reg_idx,
+ u16 addr_low, u32 value, u32 mask)
+{
+ struct cmdq_instruction inst = {};
+ int err;
+
+ inst.op = CMDQ_CODE_MASK;
+ inst.mask = ~mask;
+ err = cmdq_pkt_append_command(pkt, inst);
+ if (err < 0)
+ return err;
+
+ inst.op = CMDQ_CODE_WRITE_S_MASK;
+ inst.sop = high_addr_reg_idx;
+ inst.offset = addr_low;
+ inst.value = value;
+
+ return cmdq_pkt_append_command(pkt, inst);
+}
+EXPORT_SYMBOL(cmdq_pkt_write_s_mask_value);
+
int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event)
{
struct cmdq_instruction inst = { {0} };
diff --git a/include/linux/soc/mediatek/mtk-cmdq.h
b/include/linux/soc/mediatek/mtk-cmdq.h
index ae73e10da274..d9390d76ee14 100644
--- a/include/linux/soc/mediatek/mtk-cmdq.h
+++ b/include/linux/soc/mediatek/mtk-cmdq.h
@@ -165,6 +165,21 @@ int cmdq_pkt_write_s_value(struct cmdq_pkt *pkt, u8
high_addr_reg_idx,
u16 addr_low, u32 value);
/**
+ * cmdq_pkt_write_s_mask_value() - append write_s command with mask to the CMDQ
+ *packet which write value to a physical
+ *address
+ * @pkt: the CMDQ packet
+ * @high_addr_reg_idx: internal register ID which contains high address of pa
+ * @addr_low: low address of pa
+ * @value: the specified target value
+ * @mask: the specified target mask
+ *
+ * Return: 0 for success; else the error code is returned
+ */
+int cmdq_pkt_write_s_mask_value(struct cmdq_pkt *pkt, u8 high_addr_reg_idx,
+ u16 addr_low, u32 value, u32 mask);
+
+/**
* cmdq_pkt_wfe() - append wait for event command to the CMDQ packet
* @pkt: the CMDQ packet
* @event: the desired event type to "wait and CLEAR"
--
1.7.9.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/4] drm: mipi-dbi: Convert logging to drm_* functions.
Convert logging of errors once from dev_err_once() to drm_err_once(). Signed-off-by: Suraj Upadhyay --- drivers/gpu/drm/drm_mipi_dbi.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_mipi_dbi.c b/drivers/gpu/drm/drm_mipi_dbi.c index 79532b9a324a..ccfb6eb1a29f 100644 --- a/drivers/gpu/drm/drm_mipi_dbi.c +++ b/drivers/gpu/drm/drm_mipi_dbi.c @@ -225,7 +225,7 @@ int mipi_dbi_buf_copy(void *dst, struct drm_framebuffer *fb, drm_fb_xrgb_to_rgb565(dst, src, fb, clip, swap); break; default: - dev_err_once(fb->dev->dev, "Format is not supported: %s\n", + drm_err_once(fb->dev, "Format is not supported: %s\n", drm_get_format_name(fb->format->format, &format_name)); return -EINVAL; @@ -295,7 +295,7 @@ static void mipi_dbi_fb_dirty(struct drm_framebuffer *fb, struct drm_rect *rect) width * height * 2); err_msg: if (ret) - dev_err_once(fb->dev->dev, "Failed to update display %d\n", ret); + drm_err_once(fb->dev, "Failed to update display %d\n", ret); drm_dev_exit(idx); } -- 2.17.1 signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 9/9] drm/mediatek: reduce clear event
No need to clear event again since event always clear before wait.
This fix depend on patch:
"soc: mediatek: cmdq: add clear option in cmdq_pkt_wfe api"
Fixes: 2f965be7f9008 ("drm/mediatek: apply CMDQ control flow")
Signed-off-by: Dennis YC Hsieh
---
drivers/gpu/drm/mediatek/mtk_drm_crtc.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index c84e7a14d4a8..ba6cf956b239 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -490,7 +490,7 @@ static void mtk_drm_crtc_hw_config(struct mtk_drm_crtc
*mtk_crtc)
mbox_flush(mtk_crtc->cmdq_client->chan, 2000);
cmdq_handle = cmdq_pkt_create(mtk_crtc->cmdq_client, PAGE_SIZE);
cmdq_pkt_clear_event(cmdq_handle, mtk_crtc->cmdq_event);
- cmdq_pkt_wfe(cmdq_handle, mtk_crtc->cmdq_event, true);
+ cmdq_pkt_wfe(cmdq_handle, mtk_crtc->cmdq_event, false);
mtk_crtc_ddp_config(crtc, cmdq_handle);
cmdq_pkt_finalize(cmdq_handle);
cmdq_pkt_flush_async(cmdq_handle, ddp_cmdq_cb, cmdq_handle);
--
1.7.9.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 06/20] Documentation: gpu/komeda-kms: eliminate duplicated word
Drop the doubled word "and". Signed-off-by: Randy Dunlap Cc: Jonathan Corbet Cc: linux-...@vger.kernel.org Cc: James (Qian) Wang Cc: Liviu Dudau Cc: Mihail Atanassov Cc: Mali DP Maintainers --- Documentation/gpu/komeda-kms.rst |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-next-20200701.orig/Documentation/gpu/komeda-kms.rst +++ linux-next-20200701/Documentation/gpu/komeda-kms.rst @@ -41,7 +41,7 @@ Compositor blends multiple layers or pix frame. its output frame can be fed into post image processor for showing it on the monitor or fed into wb_layer and written to memory at the same time. user can also insert a scaler between compositor and wb_layer to down scale -the display frame first and and then write to memory. +the display frame first and then write to memory. Writeback Layer (wb_layer) -- ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/4] drm: core: Convert logging to drm_* functions.
This patchset converts logging to drm_* functions in drm core. The following functions have been converted to their respective DRM alternatives : dev_info() --> drm_info() dev_err() --> drm_err() dev_warn() --> drm_warn() dev_err_once() --> drm_err_once(). Suraj Upadhyay (4): drm: mipi-dsi: Convert logging to drm_* functions. drm: mipi-dbi: Convert logging to drm_* functions. drm: edid: Convert logging to drm_* functions. drm: fb-helper: Convert logging to drm_* functions. drivers/gpu/drm/drm_edid.c | 7 +++ drivers/gpu/drm/drm_fb_helper.c | 2 +- drivers/gpu/drm/drm_mipi_dbi.c | 4 ++-- drivers/gpu/drm/drm_mipi_dsi.c | 15 +++ 4 files changed, 13 insertions(+), 15 deletions(-) -- 2.17.1 signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 8/9] soc: mediatek: cmdq: add clear option in cmdq_pkt_wfe api
Add clear parameter to let client decide if
event should be clear to 0 after GCE receive it.
Change since v2:
- Keep behavior in drm crtc driver and
separate bug fix code into another patch.
Signed-off-by: Dennis YC Hsieh
---
drivers/gpu/drm/mediatek/mtk_drm_crtc.c |2 +-
drivers/soc/mediatek/mtk-cmdq-helper.c |5 +++--
include/linux/mailbox/mtk-cmdq-mailbox.h |3 +--
include/linux/soc/mediatek/mtk-cmdq.h|5 +++--
4 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index ec6c9ffbf35e..c84e7a14d4a8 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -490,7 +490,7 @@ static void mtk_drm_crtc_hw_config(struct mtk_drm_crtc
*mtk_crtc)
mbox_flush(mtk_crtc->cmdq_client->chan, 2000);
cmdq_handle = cmdq_pkt_create(mtk_crtc->cmdq_client, PAGE_SIZE);
cmdq_pkt_clear_event(cmdq_handle, mtk_crtc->cmdq_event);
- cmdq_pkt_wfe(cmdq_handle, mtk_crtc->cmdq_event);
+ cmdq_pkt_wfe(cmdq_handle, mtk_crtc->cmdq_event, true);
mtk_crtc_ddp_config(crtc, cmdq_handle);
cmdq_pkt_finalize(cmdq_handle);
cmdq_pkt_flush_async(cmdq_handle, ddp_cmdq_cb, cmdq_handle);
diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c
b/drivers/soc/mediatek/mtk-cmdq-helper.c
index d55dc3296105..505651b0d715 100644
--- a/drivers/soc/mediatek/mtk-cmdq-helper.c
+++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
@@ -316,15 +316,16 @@ int cmdq_pkt_write_s_mask_value(struct cmdq_pkt *pkt, u8
high_addr_reg_idx,
}
EXPORT_SYMBOL(cmdq_pkt_write_s_mask_value);
-int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event)
+int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event, bool clear)
{
struct cmdq_instruction inst = { {0} };
+ u32 clear_option = clear ? CMDQ_WFE_UPDATE : 0;
if (event >= CMDQ_MAX_EVENT)
return -EINVAL;
inst.op = CMDQ_CODE_WFE;
- inst.value = CMDQ_WFE_OPTION;
+ inst.value = CMDQ_WFE_OPTION | clear_option;
inst.event = event;
return cmdq_pkt_append_command(pkt, inst);
diff --git a/include/linux/mailbox/mtk-cmdq-mailbox.h
b/include/linux/mailbox/mtk-cmdq-mailbox.h
index efbd8a9eb2d1..d5a983d65f05 100644
--- a/include/linux/mailbox/mtk-cmdq-mailbox.h
+++ b/include/linux/mailbox/mtk-cmdq-mailbox.h
@@ -28,8 +28,7 @@
* bit 16-27: update value
* bit 31: 1 - update, 0 - no update
*/
-#define CMDQ_WFE_OPTION(CMDQ_WFE_UPDATE |
CMDQ_WFE_WAIT | \
- CMDQ_WFE_WAIT_VALUE)
+#define CMDQ_WFE_OPTION(CMDQ_WFE_WAIT |
CMDQ_WFE_WAIT_VALUE)
/** cmdq event maximum */
#define CMDQ_MAX_EVENT 0x3ff
diff --git a/include/linux/soc/mediatek/mtk-cmdq.h
b/include/linux/soc/mediatek/mtk-cmdq.h
index 34354e952f60..960704d75994 100644
--- a/include/linux/soc/mediatek/mtk-cmdq.h
+++ b/include/linux/soc/mediatek/mtk-cmdq.h
@@ -182,11 +182,12 @@ int cmdq_pkt_write_s_mask_value(struct cmdq_pkt *pkt, u8
high_addr_reg_idx,
/**
* cmdq_pkt_wfe() - append wait for event command to the CMDQ packet
* @pkt: the CMDQ packet
- * @event: the desired event type to "wait and CLEAR"
+ * @event: the desired event type to wait
+ * @clear: clear event or not after event arrive
*
* Return: 0 for success; else the error code is returned
*/
-int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event);
+int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event, bool clear);
/**
* cmdq_pkt_clear_event() - append clear event command to the CMDQ packet
--
1.7.9.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/of: Consider the state in which the ep is disabled
don't mask possible_crtcs if remote-point is disabled.
Signed-off-by: Sandy Huang
---
drivers/gpu/drm/drm_of.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c
index fdb05fbf72a0..565f05f5f11b 100644
--- a/drivers/gpu/drm/drm_of.c
+++ b/drivers/gpu/drm/drm_of.c
@@ -66,6 +66,9 @@ uint32_t drm_of_find_possible_crtcs(struct drm_device *dev,
uint32_t possible_crtcs = 0;
for_each_endpoint_of_node(port, ep) {
+ if (!of_device_is_available(ep))
+ continue;
+
remote_port = of_graph_get_remote_port(ep);
if (!remote_port) {
of_node_put(ep);
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 14/14] phy/rockchip: inno-hdmi: Support more pre-pll configuration
Hi,
What's the status for this patch?
This is just what I needed for A95X Z2 to get the vop+hdmi and monitor
working. ;)
Could this become applied to mainline already?
The ack is already there.
Thanks,
Johan Jonker
https://lore.kernel.org/lkml/20200620134659.4592-1-jbx6...@gmail.com/
On 1/8/20 10:07 PM, Jonas Karlman wrote:
> From: Algea Cao
>
> Adding the following freq cfg in 8-bit and 10-bit color depth:
>
> {
> 4000, 6500, 7100, 8350, 8575,
> 8875, 10800, 11900, 16200
> }
>
> New freq has been validated by quantumdata 980.
>
> For some freq which can't be got by only using integer freq div,
> frac freq div is needed, Such as 88.75Mhz 10-bit. But The actual
> freq is different from the target freq, We must try to narrow
> the gap between them. RK322X only support integer freq div.
>
> The VCO of pre-PLL must be more than 2Ghz, otherwise PLL may be
> unlocked.
>
> Signed-off-by: Algea Cao
> Signed-off-by: Jonas Karlman
> Acked-by: Heiko Stuebner
> ---
> drivers/phy/rockchip/phy-rockchip-inno-hdmi.c | 74 ---
> 1 file changed, 49 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
> b/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
> index 3719309ad0d0..bb8bdf5e3301 100644
> --- a/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
> +++ b/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
> @@ -291,32 +291,56 @@ struct inno_hdmi_phy_drv_data {
> const struct phy_config *phy_cfg_table;
> };
>
> +/*
> + * If only using integer freq div can't get frequency we want, frac
> + * freq div is needed. For example, pclk 88.75 Mhz and tmdsclk
> + * 110.9375 Mhz must use frac div 0xF0. The actual frequency is different
> + * from the target frequency. Such as the tmds clock 110.9375 Mhz,
> + * the actual tmds clock we get is 110.93719 Mhz. It is important
> + * to note that RK322X platforms do not support frac div.
> + */
> static const struct pre_pll_config pre_pll_cfg_table[] = {
> - { 2700, 2700, 1, 90, 3, 2, 2, 10, 3, 3, 4, 0, 0},
> - { 2700, 3375, 1, 90, 1, 3, 3, 10, 3, 3, 4, 0, 0},
> - { 4000, 4000, 1, 80, 2, 2, 2, 12, 2, 2, 2, 0, 0},
> - { 59341000, 59341000, 1, 98, 3, 1, 2, 1, 3, 3, 4, 0, 0xE6AE6B},
> - { 5940, 5940, 1, 99, 3, 1, 1, 1, 3, 3, 4, 0, 0},
> - { 59341000, 74176250, 1, 98, 0, 3, 3, 1, 3, 3, 4, 0, 0xE6AE6B},
> - { 5940, 7425, 1, 99, 1, 2, 2, 1, 3, 3, 4, 0, 0},
> - { 74176000, 74176000, 1, 98, 1, 2, 2, 1, 2, 3, 4, 0, 0xE6AE6B},
> - { 7425, 7425, 1, 99, 1, 2, 2, 1, 2, 3, 4, 0, 0},
> - { 74176000, 9272, 4, 494, 1, 2, 2, 1, 3, 3, 4, 0, 0x816817},
> - { 7425, 92812500, 4, 495, 1, 2, 2, 1, 3, 3, 4, 0, 0},
> - {148352000, 148352000, 1, 98, 1, 1, 1, 1, 2, 2, 2, 0, 0xE6AE6B},
> - {14850, 14850, 1, 99, 1, 1, 1, 1, 2, 2, 2, 0, 0},
> - {148352000, 18544, 4, 494, 0, 2, 2, 1, 3, 2, 2, 0, 0x816817},
> - {14850, 185625000, 4, 495, 0, 2, 2, 1, 3, 2, 2, 0, 0},
> - {296703000, 296703000, 1, 98, 0, 1, 1, 1, 0, 2, 2, 0, 0xE6AE6B},
> - {29700, 29700, 1, 99, 0, 1, 1, 1, 0, 2, 2, 0, 0},
> - {296703000, 370878750, 4, 494, 1, 2, 0, 1, 3, 1, 1, 0, 0x816817},
> - {29700, 37125, 4, 495, 1, 2, 0, 1, 3, 1, 1, 0, 0},
> - {593407000, 296703500, 1, 98, 0, 1, 1, 1, 0, 2, 1, 0, 0xE6AE6B},
> - {59400, 29700, 1, 99, 0, 1, 1, 1, 0, 2, 1, 0, 0},
> - {593407000, 370879375, 4, 494, 1, 2, 0, 1, 3, 1, 1, 1, 0x816817},
> - {59400, 37125, 4, 495, 1, 2, 0, 1, 3, 1, 1, 1, 0},
> - {593407000, 593407000, 1, 98, 0, 2, 0, 1, 0, 1, 1, 0, 0xE6AE6B},
> - {59400, 59400, 1, 99, 0, 2, 0, 1, 0, 1, 1, 0, 0},
> + { 2700, 2700, 1, 90, 3, 2, 2, 10, 3, 3, 4, 0, 0},
> + { 2700, 3375, 1, 90, 1, 3, 3, 10, 3, 3, 4, 0, 0},
> + { 4000, 4000, 1, 80, 2, 2, 2, 12, 2, 2, 2, 0, 0},
> + { 4000, 5000, 1, 100, 2, 2, 2, 1, 0, 0, 15, 0, 0},
> + { 59341000, 59341000, 1, 98, 3, 1, 2, 1, 3, 3, 4, 0, 0xE6AE6B},
> + { 5940, 5940, 1, 99, 3, 1, 1, 1, 3, 3, 4, 0, 0},
> + { 59341000, 74176250, 1, 98, 0, 3, 3, 1, 3, 3, 4, 0, 0xE6AE6B},
> + { 5940, 7425, 1, 99, 1, 2, 2, 1, 3, 3, 4, 0, 0},
> + { 6500, 6500, 1, 130, 2, 2, 2, 1, 0, 0, 12, 0, 0},
> + { 6500, 8125, 3, 325, 0, 3, 3, 1, 0, 0, 10, 0, 0},
> + { 7100, 7100, 3, 284, 0, 3, 3, 1, 0, 0, 8, 0, 0},
> + { 7100, 8875, 3, 355, 0, 3, 3, 1, 0, 0, 10, 0, 0},
> + { 74176000, 74176000, 1, 98, 1, 2, 2, 1, 2, 3, 4, 0, 0xE6AE6B},
> + { 7425, 7425, 1, 99, 1, 2, 2, 1, 2, 3, 4, 0, 0},
> + { 74176000, 9272, 4, 494, 1, 2, 2, 1, 3, 3, 4, 0, 0x816817},
> + { 7425, 92812500, 4, 495, 1, 2, 2, 1, 3, 3, 4, 0, 0},
> + { 8350, 8350, 2, 167, 2, 1, 1, 1, 0,
[PATCH v3 5/9] soc: mediatek: cmdq: add write_s value function
add write_s function in cmdq helper functions which
writes a constant value to address with large dma
access support.
Signed-off-by: Dennis YC Hsieh
---
drivers/soc/mediatek/mtk-cmdq-helper.c | 14 ++
include/linux/soc/mediatek/mtk-cmdq.h | 13 +
2 files changed, 27 insertions(+)
diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c
b/drivers/soc/mediatek/mtk-cmdq-helper.c
index ed9f5e63c195..4e86b65815fc 100644
--- a/drivers/soc/mediatek/mtk-cmdq-helper.c
+++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
@@ -280,6 +280,20 @@ int cmdq_pkt_write_s_mask(struct cmdq_pkt *pkt, u16
high_addr_reg_idx,
}
EXPORT_SYMBOL(cmdq_pkt_write_s_mask);
+int cmdq_pkt_write_s_value(struct cmdq_pkt *pkt, u8 high_addr_reg_idx,
+ u16 addr_low, u32 value)
+{
+ struct cmdq_instruction inst = {};
+
+ inst.op = CMDQ_CODE_WRITE_S;
+ inst.sop = high_addr_reg_idx;
+ inst.offset = addr_low;
+ inst.value = value;
+
+ return cmdq_pkt_append_command(pkt, inst);
+}
+EXPORT_SYMBOL(cmdq_pkt_write_s_value);
+
int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event)
{
struct cmdq_instruction inst = { {0} };
diff --git a/include/linux/soc/mediatek/mtk-cmdq.h
b/include/linux/soc/mediatek/mtk-cmdq.h
index cd7ec714344e..ae73e10da274 100644
--- a/include/linux/soc/mediatek/mtk-cmdq.h
+++ b/include/linux/soc/mediatek/mtk-cmdq.h
@@ -152,6 +152,19 @@ int cmdq_pkt_write_s_mask(struct cmdq_pkt *pkt, u16
high_addr_reg_idx,
u16 addr_low, u16 src_reg_idx, u32 mask);
/**
+ * cmdq_pkt_write_s_value() - append write_s command to the CMDQ packet which
+ * write value to a physical address
+ * @pkt: the CMDQ packet
+ * @high_addr_reg_idx: internal register ID which contains high address of pa
+ * @addr_low: low address of pa
+ * @value: the specified target value
+ *
+ * Return: 0 for success; else the error code is returned
+ */
+int cmdq_pkt_write_s_value(struct cmdq_pkt *pkt, u8 high_addr_reg_idx,
+ u16 addr_low, u32 value);
+
+/**
* cmdq_pkt_wfe() - append wait for event command to the CMDQ packet
* @pkt: the CMDQ packet
* @event: the desired event type to "wait and CLEAR"
--
1.7.9.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 07/20] Documentation: gpu/drm-uapi: eliminate duplicated word
Drop the doubled word "when". Signed-off-by: Randy Dunlap Cc: Jonathan Corbet Cc: linux-...@vger.kernel.org Cc: David Airlie Cc: Daniel Vetter Cc: dri-devel@lists.freedesktop.org --- Documentation/gpu/drm-uapi.rst |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-next-20200701.orig/Documentation/gpu/drm-uapi.rst +++ linux-next-20200701/Documentation/gpu/drm-uapi.rst @@ -195,7 +195,7 @@ ENOSPC: EPERM/EACCES: Returned for an operation that is valid, but needs more privileges. E.g. root-only or much more common, DRM master-only operations return -this when when called by unpriviledged clients. There's no clear +this when called by unpriviledged clients. There's no clear difference between EACCES and EPERM. ENODEV: ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 13/20] Documentation: mips/ingenic-tcu: eliminate duplicated word
Hi, Le mar. 7 juil. 2020 à 11:04, Randy Dunlap a écrit : Drop the doubled word "to". Signed-off-by: Randy Dunlap Cc: Jonathan Corbet Cc: linux-...@vger.kernel.org Cc: Paul Cercueil Cc: Thomas Bogendoerfer Cc: linux-m...@vger.kernel.org Reviewed-by: Paul Cercueil Cheers, -Paul --- Documentation/mips/ingenic-tcu.rst |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-next-20200701.orig/Documentation/mips/ingenic-tcu.rst +++ linux-next-20200701/Documentation/mips/ingenic-tcu.rst @@ -5,7 +5,7 @@ Ingenic JZ47xx SoCs Timer/Counter Unit h === The Timer/Counter Unit (TCU) in Ingenic JZ47xx SoCs is a multi-function -hardware block. It features up to to eight channels, that can be used as +hardware block. It features up to eight channels, that can be used as counters, timers, or PWM. - JZ4725B, JZ4750, JZ4755 only have six TCU channels. The other SoCs all ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/panel-simple: Add 50 Hz mode to the Frida FRD350H54004 panel
By changing the pixel clock and the length of the back porch, it is
possible to obtain a perfect 50 Hz refresh rate.
Signed-off-by: Paul Cercueil
---
drivers/gpu/drm/panel/panel-simple.c | 43 +++-
1 file changed, 29 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 1188d191076b..bebcc31e2484 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1692,23 +1692,38 @@ static const struct panel_desc foxlink_fl500wvr00_a0t =
{
.bus_format = MEDIA_BUS_FMT_RGB888_1X24,
};
-static const struct drm_display_mode frida_frd350h54004_mode = {
- .clock = 6000,
- .hdisplay = 320,
- .hsync_start = 320 + 44,
- .hsync_end = 320 + 44 + 16,
- .htotal = 320 + 44 + 16 + 20,
- .vdisplay = 240,
- .vsync_start = 240 + 2,
- .vsync_end = 240 + 2 + 6,
- .vtotal = 240 + 2 + 6 + 2,
- .vrefresh = 60,
- .flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC,
+static const struct drm_display_mode frida_frd350h54004_modes[] = {
+ { /* 60 Hz */
+ .clock = 6000,
+ .hdisplay = 320,
+ .hsync_start = 320 + 44,
+ .hsync_end = 320 + 44 + 16,
+ .htotal = 320 + 44 + 16 + 20,
+ .vdisplay = 240,
+ .vsync_start = 240 + 2,
+ .vsync_end = 240 + 2 + 6,
+ .vtotal = 240 + 2 + 6 + 2,
+ .vrefresh = 60,
+ .flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC,
+ },
+ { /* 50 Hz */
+ .clock = 5400,
+ .hdisplay = 320,
+ .hsync_start = 320 + 56,
+ .hsync_end = 320 + 56 + 16,
+ .htotal = 320 + 56 + 16 + 40,
+ .vdisplay = 240,
+ .vsync_start = 240 + 2,
+ .vsync_end = 240 + 2 + 6,
+ .vtotal = 240 + 2 + 6 + 2,
+ .vrefresh = 50,
+ .flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC,
+ },
};
static const struct panel_desc frida_frd350h54004 = {
- .modes = &frida_frd350h54004_mode,
- .num_modes = 1,
+ .modes = frida_frd350h54004_modes,
+ .num_modes = ARRAY_SIZE(frida_frd350h54004_modes),
.bpc = 8,
.size = {
.width = 77,
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 08/20] Documentation: hid/intel-ish-hid: eliminate duplicated word
Drop the doubled word "the". Signed-off-by: Randy Dunlap Cc: Jonathan Corbet Cc: linux-...@vger.kernel.org Cc: Srinivas Pandruvada Cc: Jiri Kosina Cc: linux-in...@vger.kernel.org --- Documentation/hid/intel-ish-hid.rst |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-next-20200701.orig/Documentation/hid/intel-ish-hid.rst +++ linux-next-20200701/Documentation/hid/intel-ish-hid.rst @@ -235,7 +235,7 @@ There can be multiple sensor clients and To ease in implantation and allow independent driver handle each client this transport layer takes advantage of Linux Bus driver model. Each -client is registered as device on the the transport bus (ishtp bus). +client is registered as device on the transport bus (ishtp bus). Enumeration sequence of messages: ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 0/9] support cmdq helper function on mt6779 platform
This patch support more gce helper function on mt6779 platform. depends on patch: support gce on mt6779 platform and depends on following applied patches soc: mediatek: cmdq: add set event function soc: mediatek: cmdq: export finalize function soc: mediatek: cmdq: add assign function Change since v2: - Keep behavior in drm crtc driver and separate bug fix code into another patch. Change since v1: - Rename cmdq_mbox_shift() to cmdq_get_shift_pa(). Dennis YC Hsieh (9): soc: mediatek: cmdq: add address shift in jump soc: mediatek: cmdq: add write_s function soc: mediatek: cmdq: add write_s_mask function soc: mediatek: cmdq: add read_s function soc: mediatek: cmdq: add write_s value function soc: mediatek: cmdq: add write_s_mask value function soc: mediatek: cmdq: add jump function soc: mediatek: cmdq: add clear option in cmdq_pkt_wfe api drm/mediatek: reduce clear event drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 2 +- drivers/soc/mediatek/mtk-cmdq-helper.c | 113 ++- include/linux/mailbox/mtk-cmdq-mailbox.h | 6 +- include/linux/soc/mediatek/mtk-cmdq.h| 93 ++- 4 files changed, 206 insertions(+), 8 deletions(-) -- 2.18.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] Host1x/TegraDRM UAPI (sync points)
02.07.2020 15:10, Mikko Perttunen пишет: > Ok, so we would have two kinds of syncpoints for the job; one > for kernel job tracking; and one that userspace can > manipulate as it wants to. > > Could we handle the job tracking syncpoint completely inside the kernel, > i.e. allocate it in kernel during job submission, and add an increment > for it at the end of the job (with condition OP_DONE)? For MLOCKing, the > kernel already needs to insert a SYNCPT_INCR(OP_DONE) + WAIT + > MLOCK_RELEASE sequence at the end of each job. If sync point is allocated within kernel, then we'll need to always patch all job's sync point increments with the ID of the allocated sync point, regardless of whether firewall enabled or not. Secondly, I'm now recalling that only one sync point could be assigned to a channel at a time on newer Tegras which support sync point protection. So it sounds like we don't really have variants other than to allocate one sync point per channel for the jobs usage if we want to be able to push multiple jobs into channel's pushbuffer, correct? ... >> Hmm, we actually should be able to have a one sync point per-channel for >> the job submission, similarly to what the current driver does! >> >> I'm keep forgetting about the waitbase existence! > > Tegra194 doesn't have waitbases, but if we are resubmitting all the jobs > anyway, can't we just recalculate wait thresholds at that time? Yes, thresholds could be recalculated + job should be re-formed at the push-time then. It also means that jobs always should be formed only at the push-time if wait-command is utilized by cmdstream since the waits always need to be patched because we won't know the thresholds until scheduler actually runs the job. > Maybe a more detailed sequence list or diagram of what happens during > submission and recovery would be useful. The textual form + code is already good enough to me. A diagram could be nice to have, although it may take a bit too much effort to create + maintain it. But I don't mind at all if you'd want to make one :) ... >>> * We should be able to keep the syncpoint refcounting based on fences. >> >> The fence doesn't need the sync point itself, it only needs to get a >> signal when the threshold is reached or when sync point is ceased. >> >> Imagine: >> >> - Process A creates sync point >> - Process A creates dma-fence from this sync point >> - Process A exports dma-fence to process B >> - Process A dies >> >> What should happen to process B? >> >> - Should dma-fence of the process B get a error signal when process A >> dies? >> - Should process B get stuck waiting endlessly for the dma-fence? >> >> This is one example of why I'm proposing that fence shouldn't be coupled >> tightly to a sync point. > > As a baseline, we should consider process B to get stuck endlessly > (until a timeout of its choosing) for the fence. In this case it is > avoidable, but if the ID/threshold pair is exported out of the fence and > is waited for otherwise, it is unavoidable. I.e. once the ID/threshold > are exported out of a fence, the waiter can only see the fence being > signaled by the threshold being reached, not by the syncpoint getting > freed. This is correct. If sync point's FD is exported or once sync point is resolved from a dma-fence, then sync point will stay alive until the last reference to the sync point is dropped. I.e. if Process A dies *after* process B started to wait on the sync point, then it will get stuck. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 2/9] soc: mediatek: cmdq: add write_s function
add write_s function in cmdq helper functions which
writes value contains in internal register to address
with large dma access support.
Signed-off-by: Dennis YC Hsieh
---
drivers/soc/mediatek/mtk-cmdq-helper.c | 19 +++
include/linux/mailbox/mtk-cmdq-mailbox.h |1 +
include/linux/soc/mediatek/mtk-cmdq.h| 19 +++
3 files changed, 39 insertions(+)
diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c
b/drivers/soc/mediatek/mtk-cmdq-helper.c
index 9faf78fbed3a..880349b3f16c 100644
--- a/drivers/soc/mediatek/mtk-cmdq-helper.c
+++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
@@ -18,6 +18,10 @@ struct cmdq_instruction {
union {
u32 value;
u32 mask;
+ struct {
+ u16 arg_c;
+ u16 src_reg;
+ };
};
union {
u16 offset;
@@ -223,6 +227,21 @@ int cmdq_pkt_write_mask(struct cmdq_pkt *pkt, u8 subsys,
}
EXPORT_SYMBOL(cmdq_pkt_write_mask);
+int cmdq_pkt_write_s(struct cmdq_pkt *pkt, u16 high_addr_reg_idx,
+u16 addr_low, u16 src_reg_idx)
+{
+ struct cmdq_instruction inst = {};
+
+ inst.op = CMDQ_CODE_WRITE_S;
+ inst.src_t = CMDQ_REG_TYPE;
+ inst.sop = high_addr_reg_idx;
+ inst.offset = addr_low;
+ inst.src_reg = src_reg_idx;
+
+ return cmdq_pkt_append_command(pkt, inst);
+}
+EXPORT_SYMBOL(cmdq_pkt_write_s);
+
int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event)
{
struct cmdq_instruction inst = { {0} };
diff --git a/include/linux/mailbox/mtk-cmdq-mailbox.h
b/include/linux/mailbox/mtk-cmdq-mailbox.h
index 05eea1aef5aa..1f76cfedb16d 100644
--- a/include/linux/mailbox/mtk-cmdq-mailbox.h
+++ b/include/linux/mailbox/mtk-cmdq-mailbox.h
@@ -60,6 +60,7 @@ enum cmdq_code {
CMDQ_CODE_JUMP = 0x10,
CMDQ_CODE_WFE = 0x20,
CMDQ_CODE_EOC = 0x40,
+ CMDQ_CODE_WRITE_S = 0x90,
CMDQ_CODE_LOGIC = 0xa0,
};
diff --git a/include/linux/soc/mediatek/mtk-cmdq.h
b/include/linux/soc/mediatek/mtk-cmdq.h
index 2249ecaf77e4..9b0c57a0063d 100644
--- a/include/linux/soc/mediatek/mtk-cmdq.h
+++ b/include/linux/soc/mediatek/mtk-cmdq.h
@@ -12,6 +12,8 @@
#include
#define CMDQ_NO_TIMEOUT0xu
+#define CMDQ_ADDR_HIGH(addr) ((u32)(((addr) >> 16) & GENMASK(31, 0)))
+#define CMDQ_ADDR_LOW(addr)((u16)(addr) | BIT(1))
struct cmdq_pkt;
@@ -103,6 +105,23 @@ int cmdq_pkt_write_mask(struct cmdq_pkt *pkt, u8 subsys,
u16 offset, u32 value, u32 mask);
/**
+ * cmdq_pkt_write_s() - append write_s command to the CMDQ packet
+ * @pkt: the CMDQ packet
+ * @high_addr_reg_idx: internal register ID which contains high address of pa
+ * @addr_low: low address of pa
+ * @src_reg_idx: the CMDQ internal register ID which cache source value
+ *
+ * Return: 0 for success; else the error code is returned
+ *
+ * Support write value to physical address without subsys. Use CMDQ_ADDR_HIGH()
+ * to get high address and call cmdq_pkt_assign() to assign value into internal
+ * reg. Also use CMDQ_ADDR_LOW() to get low address for addr_low parameter when
+ * call to this function.
+ */
+int cmdq_pkt_write_s(struct cmdq_pkt *pkt, u16 high_addr_reg_idx,
+u16 addr_low, u16 src_reg_idx);
+
+/**
* cmdq_pkt_wfe() - append wait for event command to the CMDQ packet
* @pkt: the CMDQ packet
* @event: the desired event type to "wait and CLEAR"
--
1.7.9.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 19/20] Documentation: virt/kvm/api: eliminate duplicated word
Drop the duplicated word "struct". Signed-off-by: Randy Dunlap Cc: Jonathan Corbet Cc: linux-...@vger.kernel.org Cc: Paolo Bonzini Cc: k...@vger.kernel.org --- Documentation/virt/kvm/api.rst |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-5.8-rc3.orig/Documentation/virt/kvm/api.rst +++ linux-5.8-rc3/Documentation/virt/kvm/api.rst @@ -3147,7 +3147,7 @@ Possible features: :Capability: basic :Architectures: arm, arm64 :Type: vm ioctl -:Parameters: struct struct kvm_vcpu_init (out) +:Parameters: struct kvm_vcpu_init (out) :Returns: 0 on success; -1 on error Errors: ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 03/20] Documentation: printk-basics: eliminate duplicated word
Drop the doubled word "the". Signed-off-by: Randy Dunlap Cc: Jonathan Corbet Cc: linux-...@vger.kernel.org --- Documentation/core-api/printk-basics.rst |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-next-20200701.orig/Documentation/core-api/printk-basics.rst +++ linux-next-20200701/Documentation/core-api/printk-basics.rst @@ -69,7 +69,7 @@ You can check the current *console_logle The result shows the *current*, *default*, *minimum* and *boot-time-default* log levels. -To change the current console_loglevel simply write the the desired level to +To change the current console_loglevel simply write the desired level to ``/proc/sys/kernel/printk``. For example, to print all messages to the console:: # echo 8 > /proc/sys/kernel/printk ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/vc4: Convert register accessors to FIELD_*
On Fri, Jul 03, 2020 at 09:57:04AM -0700, Eric Anholt wrote: > On Fri, Jul 3, 2020 at 6:57 AM Maxime Ripard wrote: > > > > The VC4_SET_FIELD and VC4_GET_FIELD are reimplementing most of the logic > > already defined in FIELD_SET and FIELD_GET. Let's convert the vc4 macros to > > use the FIELD_* macros. > > > > Signed-off-by: Maxime Ripard > > --- > > Reviewed-by: Eric Anholt Applied, thanks! Maxime signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/4] drm: edid: Convert logging to drm_* functions.
Change logging of warnings to drm_warn() form dev_warn().
Signed-off-by: Suraj Upadhyay
---
drivers/gpu/drm/drm_edid.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 31496b6cfc56..ad7a1f9817ed 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1844,9 +1844,8 @@ static void connector_bad_edid(struct drm_connector
*connector,
if (connector->bad_edid_counter++ && !drm_debug_enabled(DRM_UT_KMS))
return;
- dev_warn(connector->dev->dev,
-"%s: EDID is invalid:\n",
-connector->name);
+ drm_warn(connector->dev, "%s: EDID is invalid:\n", connector->name);
+
for (i = 0; i < num_blocks; i++) {
u8 *block = edid + i * EDID_LENGTH;
char prefix[20];
@@ -5284,7 +5283,7 @@ int drm_add_edid_modes(struct drm_connector *connector,
struct edid *edid)
}
if (!drm_edid_is_valid(edid)) {
clear_eld(connector);
- dev_warn(connector->dev->dev, "%s: EDID invalid.\n",
+ drm_warn(connector->dev, "%s: EDID invalid.\n",
connector->name);
return 0;
}
--
2.17.1
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: imx: Fix occasional screen corruption on modeset.
When performing a modeset the atomic core calls
ipu_crtc_atomic_disable() which switches off the DC and DI.
When we immediately restart as in the modeset case this sometimes
leads to corruption at the bottom of the screen looking like a mirror
image of the top.
The exact reason isn't understood but it seems timing related.
This was observed on i.MX6DL on a system that does 2 mode
transitions on boot (fbcon->android boot animation->android homescreen)
then no more during normal operation resulting in corruption
about once every 10 boots that lasted for variable durations
from a few seconds to several hours.
Dumping the buffers confirmed that they were correct in memory,
just the display was wrong.
For tests the problem was reproduced systematically by forcing
a full modeset every 10 frames even if when not required.
Leaving the DC and DI on if the CRTC is staying on fixes this.
Signed-off-by: Martin Fuzzey
---
drivers/gpu/drm/imx/ipuv3-crtc.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/imx/ipuv3-crtc.c b/drivers/gpu/drm/imx/ipuv3-crtc.c
index 63c0284..9137b64 100644
--- a/drivers/gpu/drm/imx/ipuv3-crtc.c
+++ b/drivers/gpu/drm/imx/ipuv3-crtc.c
@@ -84,8 +84,15 @@ static void ipu_crtc_atomic_disable(struct drm_crtc *crtc,
struct ipu_crtc *ipu_crtc = to_ipu_crtc(crtc);
struct ipu_soc *ipu = dev_get_drvdata(ipu_crtc->dev->parent);
- ipu_dc_disable_channel(ipu_crtc->dc);
- ipu_di_disable(ipu_crtc->di);
+ /*
+* If we are just doing a modeset don't disable dc/di as that
+* sometimes leads to corruption at the bottom of the screen
+*/
+ if (!crtc->state->active) {
+ ipu_dc_disable_channel(ipu_crtc->dc);
+ ipu_di_disable(ipu_crtc->di);
+ }
+
/*
* Planes must be disabled before DC clock is removed, as otherwise the
* attached IDMACs will be left in undefined state, possibly hanging
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 09/20] Documentation: i2c: eliminate duplicated word
Drop doubled word "new". Signed-off-by: Randy Dunlap Cc: Jonathan Corbet Cc: linux-...@vger.kernel.org Cc: Wolfram Sang Cc: linux-...@vger.kernel.org --- Documentation/i2c/upgrading-clients.rst |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-next-20200701.orig/Documentation/i2c/upgrading-clients.rst +++ linux-next-20200701/Documentation/i2c/upgrading-clients.rst @@ -8,7 +8,7 @@ Introduction This guide outlines how to alter existing Linux 2.6 client drivers from -the old to the new new binding methods. +the old to the new binding methods. Example old-style driver ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 17/20] Documentation: scsi/advansys: eliminate duplicated word
Drop the doubled word "be". Signed-off-by: Randy Dunlap Cc: Jonathan Corbet Cc: linux-...@vger.kernel.org Cc: Matthew Wilcox Cc: Hannes Reinecke Cc: linux-s...@vger.kernel.org Cc: "James E.J. Bottomley" Cc: "Martin K. Petersen" --- Documentation/scsi/advansys.rst |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-next-20200701.orig/Documentation/scsi/advansys.rst +++ linux-next-20200701/Documentation/scsi/advansys.rst @@ -125,7 +125,7 @@ The following constants can be defined i c. klogd is started with the appropriate -c parameter (e.g. klogd -c 8) - This will cause printk() messages to be be displayed on the + This will cause printk() messages to be displayed on the current console. Refer to the klogd(8) and syslogd(8) man pages for details. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 02/20] Documentation: block: eliminate duplicated word
Change the doubled word "the" to "to the". Signed-off-by: Randy Dunlap Cc: Jonathan Corbet Cc: linux-...@vger.kernel.org Cc: Jens Axboe Cc: linux-bl...@vger.kernel.org --- Documentation/block/pr.rst |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-next-20200701.orig/Documentation/block/pr.rst +++ linux-next-20200701/Documentation/block/pr.rst @@ -9,7 +9,7 @@ access to block devices to specific init setup. This document gives a general overview of the support ioctl commands. -For a more detailed reference please refer the the SCSI Primary +For a more detailed reference please refer to the SCSI Primary Commands standard, specifically the section on Reservations and the "PERSISTENT RESERVE IN" and "PERSISTENT RESERVE OUT" commands. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/msm/dp: Add DP compliance tests on Snapdragon Chipsets
add event thread to execute events serially from event queue. Also
timeout mode is supported which allow an event be deferred to be
executed at later time. Both link and phy compliant tests had been
done successfully.
This change depends-on following series:
https://lore.kernel.org/dri-devel/20200630184507.15589-1-tan...@codeaurora.org/
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 12 +-
drivers/gpu/drm/msm/dp/dp_aux.c | 4 +
drivers/gpu/drm/msm/dp/dp_aux.h | 1 +
drivers/gpu/drm/msm/dp/dp_catalog.c | 78 ++-
drivers/gpu/drm/msm/dp/dp_ctrl.c| 361 +++
drivers/gpu/drm/msm/dp/dp_ctrl.h| 3 +-
drivers/gpu/drm/msm/dp/dp_display.c | 654 +---
drivers/gpu/drm/msm/dp/dp_hpd.c | 2 +-
drivers/gpu/drm/msm/dp/dp_hpd.h | 1 +
drivers/gpu/drm/msm/dp/dp_link.c| 22 +-
drivers/gpu/drm/msm/dp/dp_panel.c | 56 +-
drivers/gpu/drm/msm/dp/dp_panel.h | 10 +-
drivers/gpu/drm/msm/dp/dp_parser.c | 45 +-
drivers/gpu/drm/msm/dp/dp_parser.h | 2 +
drivers/gpu/drm/msm/dp/dp_power.c | 32 +-
drivers/gpu/drm/msm/dp/dp_power.h | 1 +
drivers/gpu/drm/msm/dp/dp_reg.h | 1 +
17 files changed, 861 insertions(+), 424 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index b439e482fc80..87b291b8d7b7 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -1183,13 +1183,6 @@ static void dpu_encoder_virt_disable(struct drm_encoder
*drm_enc)
dpu_kms = to_dpu_kms(priv->kms);
global_state = dpu_kms_get_existing_global_state(dpu_kms);
- if (drm_enc->encoder_type == DRM_MODE_ENCODER_TMDS && priv->dp) {
- if (msm_dp_display_disable(priv->dp, drm_enc)) {
- DPU_ERROR_ENC(dpu_enc, "dp display disable failed\n");
- return;
- }
- }
-
trace_dpu_enc_disable(DRMID(drm_enc));
/* wait for idle */
@@ -1220,6 +1213,11 @@ static void dpu_encoder_virt_disable(struct drm_encoder
*drm_enc)
dpu_rm_release(global_state, drm_enc);
+ if (drm_enc->encoder_type == DRM_MODE_ENCODER_TMDS && priv->dp) {
+ if (msm_dp_display_disable(priv->dp, drm_enc))
+ DPU_ERROR_ENC(dpu_enc, "dp display disable failed\n");
+ }
+
mutex_unlock(&dpu_enc->enc_lock);
}
diff --git a/drivers/gpu/drm/msm/dp/dp_aux.c b/drivers/gpu/drm/msm/dp/dp_aux.c
index 696dc8741f1e..c0e8ad031895 100644
--- a/drivers/gpu/drm/msm/dp/dp_aux.c
+++ b/drivers/gpu/drm/msm/dp/dp_aux.c
@@ -189,6 +189,8 @@ static void dp_aux_native_handler(struct dp_aux_private
*aux)
aux->aux_error_num = DP_AUX_ERR_TOUT;
if (isr & DP_INTR_NACK_DEFER)
aux->aux_error_num = DP_AUX_ERR_NACK;
+ if (isr & DP_INTR_AUX_ERROR)
+ aux->aux_error_num = DP_AUX_ERR_DPPHY_AUX;
complete(&aux->comp);
}
@@ -359,6 +361,8 @@ static ssize_t dp_aux_transfer(struct drm_dp_aux *dp_aux,
PHY_AUX_CFG1);
dp_catalog_aux_reset(aux->catalog);
}
+ if (aux->aux_error_num == DP_AUX_ERR_DPPHY_AUX)
+ usleep_range(400, 400); /* need 400us before next try */
goto unlock_exit;
}
diff --git a/drivers/gpu/drm/msm/dp/dp_aux.h b/drivers/gpu/drm/msm/dp/dp_aux.h
index 2de11021d84a..1fbdfc9aa62e 100644
--- a/drivers/gpu/drm/msm/dp/dp_aux.h
+++ b/drivers/gpu/drm/msm/dp/dp_aux.h
@@ -15,6 +15,7 @@
#define DP_AUX_ERR_NACK-3
#define DP_AUX_ERR_DEFER -4
#define DP_AUX_ERR_NACK_DEFER -5
+#define DP_AUX_ERR_DPPHY_AUX -6
int dp_aux_register(struct drm_dp_aux *dp_aux);
void dp_aux_unregister(struct drm_dp_aux *dp_aux);
diff --git a/drivers/gpu/drm/msm/dp/dp_catalog.c
b/drivers/gpu/drm/msm/dp/dp_catalog.c
index ab69ae3e2dbd..367eb54c9a68 100644
--- a/drivers/gpu/drm/msm/dp/dp_catalog.c
+++ b/drivers/gpu/drm/msm/dp/dp_catalog.c
@@ -452,7 +452,6 @@ void dp_catalog_aux_setup(struct dp_catalog *dp_catalog)
dp_write_phy(catalog, REG_DP_PHY_PD_CTL, DP_PHY_PD_CTL_PSR_PWRDN);
/* Make sure that hardware is done with PSR power down */
- wmb();
dp_write_phy(catalog, REG_DP_PHY_PD_CTL, DP_PHY_PD_CTL_PWRDN |
DP_PHY_PD_CTL_AUX_PWRDN | DP_PHY_PD_CTL_LANE_0_1_PWRDN
| DP_PHY_PD_CTL_LANE_2_3_PWRDN | DP_PHY_PD_CTL_PLL_PWRDN
@@ -554,16 +553,21 @@ void dp_catalog_ctrl_mainlink_ctrl(struct dp_catalog
*dp_catalog,
* To make sure link reg writes happens before other operation,
* dp_write_link() function uses writel()
*/
- dp_write_link(catalog, REG_DP_MAINLINK_CTRL,
-
[PATCH 20/20] Documentation: vm/memory-model: eliminate duplicated word
Drop the doubled word "the". Signed-off-by: Randy Dunlap Cc: Jonathan Corbet Cc: linux-...@vger.kernel.org Cc: Andrew Morton Cc: linux...@kvack.org --- Documentation/vm/memory-model.rst |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-next-20200701.orig/Documentation/vm/memory-model.rst +++ linux-next-20200701/Documentation/vm/memory-model.rst @@ -159,7 +159,7 @@ frame. Inside a section, the PFN is the The sparse vmemmap uses a virtually mapped memory map to optimize pfn_to_page and page_to_pfn operations. There is a global `struct page *vmemmap` pointer that points to a virtually contiguous array of -`struct page` objects. A PFN is an index to that array and the the +`struct page` objects. A PFN is an index to that array and the offset of the `struct page` from `vmemmap` is the PFN of that page. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 16/20] Documentation: s390/vfio-ap: eliminate duplicated word
Drop the doubled word "the". Signed-off-by: Randy Dunlap Cc: Jonathan Corbet Cc: linux-...@vger.kernel.org Cc: Tony Krowiak Cc: Pierre Morel Cc: Halil Pasic Cc: linux-s...@vger.kernel.org --- Documentation/s390/vfio-ap.rst |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-next-20200701.orig/Documentation/s390/vfio-ap.rst +++ linux-next-20200701/Documentation/s390/vfio-ap.rst @@ -361,7 +361,7 @@ matrix device. assign_domain / unassign_domain: Write-only attributes for assigning/unassigning an AP usage domain to/from the mediated matrix device. To assign/unassign a domain, the domain - number of the the usage domain is echoed to the respective attribute + number of the usage domain is echoed to the respective attribute file. matrix: A read-only file for displaying the APQNs derived from the cross product ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 18/20] Documentation: security/keys: eliminate duplicated word
Drop the doubled word "in". Signed-off-by: Randy Dunlap Cc: Jonathan Corbet Cc: linux-...@vger.kernel.org Cc: James Bottomley Cc: Jarkko Sakkinen Cc: Mimi Zohar Cc: linux-integr...@vger.kernel.org Cc: keyri...@vger.kernel.org --- Documentation/security/keys/trusted-encrypted.rst |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-next-20200701.orig/Documentation/security/keys/trusted-encrypted.rst +++ linux-next-20200701/Documentation/security/keys/trusted-encrypted.rst @@ -200,7 +200,7 @@ Load an encrypted key "evm" from saved b 24717c64 5972dcb82ab2dde83376d82b2e3c09ffc Other uses for trusted and encrypted keys, such as for disk and file encryption -are anticipated. In particular the new format 'ecryptfs' has been defined in +are anticipated. In particular the new format 'ecryptfs' has been defined in order to use encrypted keys to mount an eCryptfs filesystem. More details about the usage can be found in the file ``Documentation/security/keys/ecryptfs.rst``. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/vgem: Do not allocate backing shmemfs file for an import dmabuf object
On Tue, Jul 7, 2020 at 9:00 AM Chris Wilson wrote:
>
> If we assign obj->filp, we believe that the create vgem bo is native and
> allow direct operations like mmap() assuming it behaves as backed by a
> shmemfs inode. When imported from a dmabuf, the obj->pages are
> not always meaningful and the shmemfs backing store misleading.
>
> Note, that regular mmap access to a vgem bo is via the dumb buffer API,
> and that rejects attempts to mmap an imported dmabuf,
>
> drm_gem_dumb_map_offset():
> if (obj->import_attach) return -EINVAL;
>
> So the only route by which we might accidentally allow mmapping of an
> imported buffer is via vgem_prime_mmap(), which checked for
> obj->filp assuming that it would be NULL.
>
> Well it would had it been updated to use the common
> drm_gem_dum_map_offset() helper, instead it has
>
> vgem_gem_dumb_map():
> if (!obj->filp) return -EINVAL;
>
> falling foul of the same trap as above.
>
> Reported-by: Lepton Wu
> Fixes: af33a9190d02 ("drm/vgem: Enable dmabuf import interfaces")
> Signed-off-by: Chris Wilson
> Cc: Lepton Wu
> Cc: Daniel Vetter
> Cc: Christian König
> Cc: Thomas Hellström (Intel)
> Cc: # v4.13+
> ---
> drivers/gpu/drm/vgem/vgem_drv.c | 27 +--
> 1 file changed, 17 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c
> index 909eba43664a..eb3b7cdac941 100644
> --- a/drivers/gpu/drm/vgem/vgem_drv.c
> +++ b/drivers/gpu/drm/vgem/vgem_drv.c
> @@ -91,7 +91,7 @@ static vm_fault_t vgem_gem_fault(struct vm_fault *vmf)
> ret = 0;
> }
> mutex_unlock(&obj->pages_lock);
> - if (ret) {
> + if (ret && obj->base.filp) {
> struct page *page;
>
> page = shmem_read_mapping_page(
> @@ -157,7 +157,8 @@ static void vgem_postclose(struct drm_device *dev, struct
> drm_file *file)
> }
>
> static struct drm_vgem_gem_object *__vgem_gem_create(struct drm_device *dev,
> - unsigned long size)
> +struct file *shmem,
> +unsigned long size)
> {
> struct drm_vgem_gem_object *obj;
> int ret;
Remove this, it's not used any more.
> @@ -166,11 +167,8 @@ static struct drm_vgem_gem_object
> *__vgem_gem_create(struct drm_device *dev,
> if (!obj)
> return ERR_PTR(-ENOMEM);
>
> - ret = drm_gem_object_init(dev, &obj->base, roundup(size, PAGE_SIZE));
> - if (ret) {
> - kfree(obj);
> - return ERR_PTR(ret);
> - }
> + drm_gem_private_object_init(dev, &obj->base, size);
> + obj->base.filp = shmem;
>
> mutex_init(&obj->pages_lock);
>
> @@ -189,11 +187,20 @@ static struct drm_gem_object *vgem_gem_create(struct
> drm_device *dev,
> unsigned long size)
> {
> struct drm_vgem_gem_object *obj;
> + struct file *shmem;
> int ret;
>
> - obj = __vgem_gem_create(dev, size);
> - if (IS_ERR(obj))
> + size = roundup(size, PAGE_SIZE);
> +
> + shmem = shmem_file_setup(DRIVER_NAME, size, VM_NORESERVE);
> + if (IS_ERR(shmem))
> + return ERR_CAST(shmem);
> +
> + obj = __vgem_gem_create(dev, shmem, size);
> + if (IS_ERR(obj)) {
> + fput(shmem);
> return ERR_CAST(obj);
> + }
>
> ret = drm_gem_handle_create(file, &obj->base, handle);
> if (ret) {
> @@ -363,7 +370,7 @@ static struct drm_gem_object
> *vgem_prime_import_sg_table(struct drm_device *dev,
> struct drm_vgem_gem_object *obj;
> int npages;
>
> - obj = __vgem_gem_create(dev, attach->dmabuf->size);
> + obj = __vgem_gem_create(dev, NULL, attach->dmabuf->size);
> if (IS_ERR(obj))
> return ERR_CAST(obj);
>
> --
> 2.27.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/2] drm: rockchip: add NV15, NV20 and NV30 support【请注意，邮件由linux-rockchip-bounces+sandy.huang=rock-chips....@lists.infradead.org代发】
在 2020/7/7 6:30, Jonas Karlman 写道:
Add support for displaying 10-bit 4:2:0 and 4:2:2 formats produced by the
Rockchip Video Decoder on RK322X, RK3288, RK3328, RK3368 and RK3399.
Also add support for 10-bit 4:4:4 format while at it.
V2: Added NV30 support
Signed-off-by: Jonas Karlman
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 29 +--
drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 1 +
drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 32 +
3 files changed, 54 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index c80f7d9fd13f..eb663e25ad9e 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -261,6 +261,18 @@ static bool has_rb_swapped(uint32_t format)
}
}
+static bool is_fmt_10(uint32_t format)
+{
+ switch (format) {
+ case DRM_FORMAT_NV15:
+ case DRM_FORMAT_NV20:
+ case DRM_FORMAT_NV30:
+ return true;
+ default:
+ return false;
+ }
+}
+
static enum vop_data_format vop_convert_format(uint32_t format)
{
switch (format) {
@@ -276,10 +288,13 @@ static enum vop_data_format vop_convert_format(uint32_t
format)
case DRM_FORMAT_BGR565:
return VOP_FMT_RGB565;
case DRM_FORMAT_NV12:
+ case DRM_FORMAT_NV15:
return VOP_FMT_YUV420SP;
case DRM_FORMAT_NV16:
+ case DRM_FORMAT_NV20:
return VOP_FMT_YUV422SP;
case DRM_FORMAT_NV24:
+ case DRM_FORMAT_NV30:
return VOP_FMT_YUV444SP;
default:
DRM_ERROR("unsupported format[%08x]\n", format);
@@ -922,7 +937,12 @@ static void vop_plane_atomic_update(struct drm_plane
*plane,
dsp_sty = dest->y1 + crtc->mode.vtotal - crtc->mode.vsync_start;
dsp_st = dsp_sty << 16 | (dsp_stx & 0x);
- offset = (src->x1 >> 16) * fb->format->cpp[0];
+ if (fb->format->block_w[0])
+ offset = (src->x1 >> 16) * fb->format->char_per_block[0] /
+fb->format->block_w[0];
+ else
+ offset = (src->x1 >> 16) * fb->format->cpp[0];
+
offset += (src->y1 >> 16) * fb->pitches[0];
dma_addr = rk_obj->dma_addr + offset + fb->offsets[0];
@@ -948,6 +968,7 @@ static void vop_plane_atomic_update(struct drm_plane *plane,
}
VOP_WIN_SET(vop, win, format, format);
+ VOP_WIN_SET(vop, win, fmt_10, is_fmt_10(fb->format->format));
VOP_WIN_SET(vop, win, yrgb_vir, DIV_ROUND_UP(fb->pitches[0], 4));
VOP_WIN_SET(vop, win, yrgb_mst, dma_addr);
VOP_WIN_YUV2YUV_SET(vop, win_yuv2yuv, y2r_en, is_yuv);
@@ -964,7 +985,11 @@ static void vop_plane_atomic_update(struct drm_plane
*plane,
uv_obj = fb->obj[1];
rk_uv_obj = to_rockchip_obj(uv_obj);
- offset = (src->x1 >> 16) * bpp / hsub;
+ if (fb->format->block_w[1])
+ offset = (src->x1 >> 16) * bpp /
+fb->format->block_w[1] / hsub;
+ else
+ offset = (src->x1 >> 16) * bpp / hsub;
offset += (src->y1 >> 16) * fb->pitches[1] / vsub;
dma_addr = rk_uv_obj->dma_addr + offset + fb->offsets[1];
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
index 4a2099cb582e..eab055d9b56d 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
@@ -154,6 +154,7 @@ struct vop_win_phy {
struct vop_reg enable;
struct vop_reg gate;
struct vop_reg format;
+ struct vop_reg fmt_10;
struct vop_reg rb_swap;
struct vop_reg act_info;
struct vop_reg dsp_info;
diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
index 80053d91a301..2c55e1852c3d 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
+++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
@@ -50,6 +50,23 @@ static const uint32_t formats_win_full[] = {
DRM_FORMAT_NV24,
};
+static const uint32_t formats_win_full_10[] = {
+ DRM_FORMAT_XRGB,
+ DRM_FORMAT_ARGB,
+ DRM_FORMAT_XBGR,
+ DRM_FORMAT_ABGR,
+ DRM_FORMAT_RGB888,
+ DRM_FORMAT_BGR888,
+ DRM_FORMAT_RGB565,
+ DRM_FORMAT_BGR565,
+ DRM_FORMAT_NV12,
+ DRM_FORMAT_NV16,
+ DRM_FORMAT_NV24,
+ DRM_FORMAT_NV15,
+ DRM_FORMAT_NV20,
+ DRM_FORMAT_NV30,
+};
+
static const uint64_t format_modifiers_win_full[] = {
DRM_FORMAT_MOD_LINEAR,
DRM_FORMAT_MOD_INVALID,
@@ -579,11 +596,12 @@ static const struct vop_scl_regs rk3288_win_full_scl = {
static const struct vop_win_phy rk3288_win01_data = {
.scl = &rk3288_win_full_scl,
- .data_formats = formats_win_full,
- .nf
[PATCH 15/20] Documentation: powerpc/vas-api: eliminate duplicated word
Drop the doubled word "the". Signed-off-by: Randy Dunlap Cc: Jonathan Corbet Cc: linux-...@vger.kernel.org Cc: Michael Ellerman Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: linuxppc-...@lists.ozlabs.org --- Documentation/powerpc/vas-api.rst |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-next-20200701.orig/Documentation/powerpc/vas-api.rst +++ linux-next-20200701/Documentation/powerpc/vas-api.rst @@ -43,7 +43,7 @@ engine for this process. Once a connecti should use the mmap() system call to map the hardware address of engine's request queue into the application's virtual address space. -The application can then submit one or more requests to the the engine by +The application can then submit one or more requests to the engine by using copy/paste instructions and pasting the CRBs to the virtual address (aka paste_address) returned by mmap(). User space can close the established connection or send window by closing the file descriptior ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/vgem: Do not allocate backing shmemfs file for an import dmabuf object
On Tue, Jul 7, 2020 at 10:20 AM Chris Wilson wrote: > > Quoting lepton (2020-07-07 18:05:21) > > On Tue, Jul 7, 2020 at 9:00 AM Chris Wilson > > wrote: > > > > > > If we assign obj->filp, we believe that the create vgem bo is native and > > > allow direct operations like mmap() assuming it behaves as backed by a > > > shmemfs inode. When imported from a dmabuf, the obj->pages are > > > not always meaningful and the shmemfs backing store misleading. > > > > > > Note, that regular mmap access to a vgem bo is via the dumb buffer API, > > > and that rejects attempts to mmap an imported dmabuf, > > What do you mean by "regular mmap access" here? It looks like vgem is > > using vgem_gem_dumb_map as .dumb_map_offset callback then it doesn't call > > drm_gem_dumb_map_offset > > As I too found out, and so had to correct my story telling. > > By regular mmap() access I mean mmap on the vgem bo [via the dumb buffer > API] as opposed to mmap() via an exported dma-buf fd. I had to look at > igt to see how it was being used. Now it seems your fix is to disable "regular mmap" on imported dma buf for vgem. I am not really a graphic guy, but then the api looks like: for a gem handle, user space has to guess to find out the way to mmap it. If user space guess wrong, then it will fail to mmap. Is this the expected way for people to handle gpu buffer? > -Chris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/vc4: dsi: Only register our component once a DSI device is attached
If the DSI driver is the last to probe, component_add will try to run all
the bind callbacks straight away and return the error code.
However, since we depend on a power domain, we're pretty much guaranteed to
be in that case on the BCM2711, and are just lucky on the previous SoCs
since the v3d also depends on that power domain and is further in the probe
order.
In that case, the DSI host will not stick around in the system: the DSI
bind callback will be executed, will not find any DSI device attached and
will return EPROBE_DEFER, and we will then remove the DSI host and ask to
be probed later on.
But since that host doesn't stick around, DSI devices like the RaspberryPi
touchscreen whose probe is not linked to the DSI host (unlike the usual DSI
devices that will be probed through the call to mipi_dsi_host_register)
cannot attach to the DSI host, and we thus end up in a situation where the
DSI host cannot probe because the panel hasn't probed yet, and the panel
cannot probe because the DSI host hasn't yet.
In order to break this cycle, let's wait until there's a DSI device that
attaches to the DSI host to register the component and allow to progress
further.
Suggested-by: Andrzej Hajda
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_dsi.c | 25 -
1 file changed, 8 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_dsi.c b/drivers/gpu/drm/vc4/vc4_dsi.c
index eaf276978ee7..19aab4e7e209 100644
--- a/drivers/gpu/drm/vc4/vc4_dsi.c
+++ b/drivers/gpu/drm/vc4/vc4_dsi.c
@@ -1246,10 +1246,12 @@ static ssize_t vc4_dsi_host_transfer(struct
mipi_dsi_host *host,
return ret;
}
+static const struct component_ops vc4_dsi_ops;
static int vc4_dsi_host_attach(struct mipi_dsi_host *host,
struct mipi_dsi_device *device)
{
struct vc4_dsi *dsi = host_to_dsi(host);
+ int ret;
dsi->lanes = device->lanes;
dsi->channel = device->channel;
@@ -1284,6 +1286,12 @@ static int vc4_dsi_host_attach(struct mipi_dsi_host
*host,
return 0;
}
+ ret = component_add(&dsi->pdev->dev, &vc4_dsi_ops);
+ if (ret) {
+ mipi_dsi_host_unregister(&dsi->dsi_host);
+ return ret;
+ }
+
return 0;
}
@@ -1662,7 +1670,6 @@ static int vc4_dsi_dev_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
struct vc4_dsi *dsi;
- int ret;
dsi = devm_kzalloc(dev, sizeof(*dsi), GFP_KERNEL);
if (!dsi)
@@ -1670,26 +1677,10 @@ static int vc4_dsi_dev_probe(struct platform_device
*pdev)
dev_set_drvdata(dev, dsi);
dsi->pdev = pdev;
-
- /* Note, the initialization sequence for DSI and panels is
-* tricky. The component bind above won't get past its
-* -EPROBE_DEFER until the panel/bridge probes. The
-* panel/bridge will return -EPROBE_DEFER until it has a
-* mipi_dsi_host to register its device to. So, we register
-* the host during pdev probe time, so vc4 as a whole can then
-* -EPROBE_DEFER its component bind process until the panel
-* successfully attaches.
-*/
dsi->dsi_host.ops = &vc4_dsi_host_ops;
dsi->dsi_host.dev = dev;
mipi_dsi_host_register(&dsi->dsi_host);
- ret = component_add(&pdev->dev, &vc4_dsi_ops);
- if (ret) {
- mipi_dsi_host_unregister(&dsi->dsi_host);
- return ret;
- }
-
return 0;
}
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 00/20] Documentation: eliminate duplicated words
On Tue, 7 Jul 2020 11:03:54 -0700, Randy Dunlap wrote: > Drop doubled words in various parts of Documentation/. > > [...] Applied to 5.9/scsi-queue, thanks! [17/20] scsi: advansys: docs: Eliminate duplicated word https://git.kernel.org/mkp/scsi/c/3010dfb0b77c -- Martin K. Petersen Oracle Linux Engineering ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/vgem: Do not allocate backing shmemfs file for an import dmabuf object
On Tue, Jul 7, 2020 at 9:00 AM Chris Wilson wrote:
>
> If we assign obj->filp, we believe that the create vgem bo is native and
> allow direct operations like mmap() assuming it behaves as backed by a
> shmemfs inode. When imported from a dmabuf, the obj->pages are
> not always meaningful and the shmemfs backing store misleading.
>
> Note, that regular mmap access to a vgem bo is via the dumb buffer API,
> and that rejects attempts to mmap an imported dmabuf,
What do you mean by "regular mmap access" here? It looks like vgem is
using vgem_gem_dumb_map as .dumb_map_offset callback then it doesn't call
drm_gem_dumb_map_offset
>
> drm_gem_dumb_map_offset():
> if (obj->import_attach) return -EINVAL;
>
> So the only route by which we might accidentally allow mmapping of an
> imported buffer is via vgem_prime_mmap(), which checked for
> obj->filp assuming that it would be NULL.
>
> Well it would had it been updated to use the common
> drm_gem_dum_map_offset() helper, instead it has
>
> vgem_gem_dumb_map():
> if (!obj->filp) return -EINVAL;
>
> falling foul of the same trap as above.
>
> Reported-by: Lepton Wu
> Fixes: af33a9190d02 ("drm/vgem: Enable dmabuf import interfaces")
> Signed-off-by: Chris Wilson
> Cc: Lepton Wu
> Cc: Daniel Vetter
> Cc: Christian König
> Cc: Thomas Hellström (Intel)
> Cc: # v4.13+
> ---
> drivers/gpu/drm/vgem/vgem_drv.c | 27 +--
> 1 file changed, 17 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c
> index 909eba43664a..eb3b7cdac941 100644
> --- a/drivers/gpu/drm/vgem/vgem_drv.c
> +++ b/drivers/gpu/drm/vgem/vgem_drv.c
> @@ -91,7 +91,7 @@ static vm_fault_t vgem_gem_fault(struct vm_fault *vmf)
> ret = 0;
> }
> mutex_unlock(&obj->pages_lock);
> - if (ret) {
> + if (ret && obj->base.filp) {
> struct page *page;
>
> page = shmem_read_mapping_page(
> @@ -157,7 +157,8 @@ static void vgem_postclose(struct drm_device *dev, struct
> drm_file *file)
> }
>
> static struct drm_vgem_gem_object *__vgem_gem_create(struct drm_device *dev,
> - unsigned long size)
> +struct file *shmem,
> +unsigned long size)
> {
> struct drm_vgem_gem_object *obj;
> int ret;
> @@ -166,11 +167,8 @@ static struct drm_vgem_gem_object
> *__vgem_gem_create(struct drm_device *dev,
> if (!obj)
> return ERR_PTR(-ENOMEM);
>
> - ret = drm_gem_object_init(dev, &obj->base, roundup(size, PAGE_SIZE));
> - if (ret) {
> - kfree(obj);
> - return ERR_PTR(ret);
> - }
> + drm_gem_private_object_init(dev, &obj->base, size);
> + obj->base.filp = shmem;
>
> mutex_init(&obj->pages_lock);
>
> @@ -189,11 +187,20 @@ static struct drm_gem_object *vgem_gem_create(struct
> drm_device *dev,
> unsigned long size)
> {
> struct drm_vgem_gem_object *obj;
> + struct file *shmem;
> int ret;
>
> - obj = __vgem_gem_create(dev, size);
> - if (IS_ERR(obj))
> + size = roundup(size, PAGE_SIZE);
> +
> + shmem = shmem_file_setup(DRIVER_NAME, size, VM_NORESERVE);
> + if (IS_ERR(shmem))
> + return ERR_CAST(shmem);
> +
> + obj = __vgem_gem_create(dev, shmem, size);
> + if (IS_ERR(obj)) {
> + fput(shmem);
> return ERR_CAST(obj);
> + }
>
> ret = drm_gem_handle_create(file, &obj->base, handle);
> if (ret) {
> @@ -363,7 +370,7 @@ static struct drm_gem_object
> *vgem_prime_import_sg_table(struct drm_device *dev,
> struct drm_vgem_gem_object *obj;
> int npages;
>
> - obj = __vgem_gem_create(dev, attach->dmabuf->size);
> + obj = __vgem_gem_create(dev, NULL, attach->dmabuf->size);
> if (IS_ERR(obj))
> return ERR_CAST(obj);
>
> --
> 2.27.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 06/20] Documentation: gpu/komeda-kms: eliminate duplicated word
On Tue, Jul 07, 2020 at 11:04:00AM -0700, Randy Dunlap wrote: > Drop the doubled word "and". > > Signed-off-by: Randy Dunlap > Cc: Jonathan Corbet > Cc: linux-...@vger.kernel.org > Cc: James (Qian) Wang > Cc: Liviu Dudau > Cc: Mihail Atanassov > Cc: Mali DP Maintainers > --- > Documentation/gpu/komeda-kms.rst |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > --- linux-next-20200701.orig/Documentation/gpu/komeda-kms.rst > +++ linux-next-20200701/Documentation/gpu/komeda-kms.rst > @@ -41,7 +41,7 @@ Compositor blends multiple layers or pix > frame. its output frame can be fed into post image processor for showing it > on > the monitor or fed into wb_layer and written to memory at the same time. > user can also insert a scaler between compositor and wb_layer to down scale > -the display frame first and and then write to memory. > +the display frame first and then write to memory. > Thank you Randy Reviewed-by: James Qian Wang > Writeback Layer (wb_layer) > -- ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 0/4] DSI/DBI and TinyDRM driver
On Tue, Jul 07, 2020 at 04:32:25PM +0200, Noralf Trønnes wrote:
> (cc Dillon)
>
> Den 03.07.2020 19.26, skrev Sam Ravnborg:
> > Hi Noralf/Paul.
> >
> > Trying to stir up this discussion again.
> >
> > On Sun, Jun 14, 2020 at 06:36:22PM +0200, Noralf Trønnes wrote:
> >>
> >>
> >> Den 07.06.2020 15.38, skrev Paul Cercueil:
> >>> Hi,
> >>>
> >>> Here's a follow-up on the previous discussion about the current state of
> >>> DSI/DBI panel drivers, TinyDRM, and the need of a cleanup.
> >>>
> >>> This patchset introduces the following:
> >>> * It slightly tweaks the MIPI DSI code so that it supports MIPI DBI over
> >>> various buses. This patch has been tested with a non-upstream DRM
> >>> panel driver for a ILI9331 DBI/8080 panel, written with the DSI
> >>> framework (and doesn't include ), and non-upstream
> >>> DSI/DBI host driver for the Ingenic SoCs.
> >>>
> >>> * A SPI DBI host driver, using the current MIPI DSI framework. It allows
> >>> MIPI DSI/DBI drivers to be written with the DSI framework, even if
> >>> they are connected over SPI, instead of registering as SPI device
> >>> drivers. Since most of these panels can be connected over various
> >>> buses, it permits to reuse the same driver independently of the bus
> >>> used.
> >>>
> >>> * A TinyDRM driver for DSI/DBI panels, once again independent of the bus
> >>> used; the only dependency (currently) being that the panel must
> >>> understand DCS commands.
> >>>
> >>> * A DRM panel driver to test the stack. This driver controls Ilitek
> >>> ILI9341 based DBI panels, like the Adafruit YX240QV29-T 320x240 2.4"
> >>> TFT LCD panel. This panel was converted from
> >>> drivers/gpu/drm/tiny/ili9341.c.
> >>>
> >>> I would like to emphasize that while it has been compile-tested, I did
> >>> not test it with real hardware since I do not have any DBI panel
> >>> connected over SPI. I did runtime-test the code, just without any panel
> >>> connected.
> >>>
> >>> Another thing to note, is that it does not break Device Tree ABI. The
> >>> display node stays the same:
> >>>
> >>> display@0 {
> >>> compatible = "adafruit,yx240qv29", "ilitek,ili9341";
> >>> reg = <0>;
> >>> spi-max-frequency = <3200>;
> >>> dc-gpios = <&gpio0 9 GPIO_ACTIVE_HIGH>;
> >>> reset-gpios = <&gpio0 8 GPIO_ACTIVE_HIGH>;
> >>> rotation = <270>;
> >>> backlight = <&backlight>;
> >>> };
> >>>
> >>> The reason it works, is that the "adafruit,yx240qv29" device is probed
> >>> on the SPI bus, so it will match with the SPI/DBI host driver. This will
> >>> in turn register the very same node with the DSI bus, and the ILI9341
> >>> DRM panel driver will probe. The driver will detect that no controller
> >>> is linked to the panel, and eventually register the DBI/DSI TinyDRM
> >>> driver.
> >>>
> >>> I can't stress it enough that this is a RFC, so it still has very rough
> >>> edges.
> >>>
> >>
> >> I don't know bridge and dsi drivers so I can't comment on that, but one
> >> thing I didn't like is that the DT compatible string has to be added to
> >> 2 different modules.
> >>
> >> As an example, a MI0283QT panel (ILI9341) supports these interface options:
> >>
> >> 1. SPI
> >>Panel setup/control and framebuffer upload over SPI
> >>
> >> 2. SPI + DPI
> >>Panel setup/control over SPI, framebuffer scanout over DPI
> >>
> >> 3. Parallel bus
> >>Panel setup/control and framebuffer upload over parallel bus
> >
> > To continue the configurations we should support:
> > - Panels where the chip can be configured to SPI, SPI+DPI, Parallel bus
> > (as detailed by Noralf above)
> > - Panels that supports only 6800 or 8080 - connected via GPIO pins or
> > memory mapped (maybe behind some special IP to support this)
> > Command set is often special.
> >
> > We will see a number of chips with many different types of displays.
> > So the drivers should be chip specific with configuration depending on
> > the connected display.
> >
> > What I hope we can find a solution for is a single file/driver that can
> > support all the relevant interface types for a chip.
> > So we would end up with a single file that included the necessary
> > support for ili9341 in all interface configurations with the necessary
> > support for the relevant displays.
> >
> > I do not know how far we are from this as I have not dived into the
> > details of any of the proposals.
>
> In an ideal world I would have liked to see the MIPI DBI parallel
> interface implemented using a new Linux parallel bus type. It could have
> drivers for gpio bitbanging and mmio in addition to other hw specific
> drivers. Now we could have a drm_mipi_dbi DRM driver that registers as a
> SPI client driver and a Parallel bus client driver. Or it can be a
> component driver for the existing DRM driver on the SoC.
>
> I had plans to do this and made a prototype, but dropped it since it
> would probably require a lot of work getting in a new Linux bus type.
Channelling my inner Greg KH:
Please ju
Re: [PATCH v3 1/9] soc: mediatek: cmdq: add address shift in jump
Reviewed-by: Bibby Hsieh On Tue, 2020-07-07 at 23:45 +0800, Dennis YC Hsieh wrote: > Add address shift when compose jump instruction > to compatible with 35bit format. > > Change since v1: > - Rename cmdq_mbox_shift() to cmdq_get_shift_pa(). > > Signed-off-by: Dennis YC Hsieh > --- > drivers/soc/mediatek/mtk-cmdq-helper.c |3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c > b/drivers/soc/mediatek/mtk-cmdq-helper.c > index dc644cfb6419..9faf78fbed3a 100644 > --- a/drivers/soc/mediatek/mtk-cmdq-helper.c > +++ b/drivers/soc/mediatek/mtk-cmdq-helper.c > @@ -329,7 +329,8 @@ int cmdq_pkt_finalize(struct cmdq_pkt *pkt) > > /* JUMP to end */ > inst.op = CMDQ_CODE_JUMP; > - inst.value = CMDQ_JUMP_PASS; > + inst.value = CMDQ_JUMP_PASS >> > + cmdq_get_shift_pa(((struct cmdq_client *)pkt->cl)->chan); > err = cmdq_pkt_append_command(pkt, inst); > > return err; ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH 2/2] drm/amdgpu: stop allocating dummy GTT nodes
[AMD Public Use]
-Original Message-
From: amd-gfx On Behalf Of Christian
König
Sent: Monday, July 6, 2020 11:18 PM
To: amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
Subject: [PATCH 2/2] drm/amdgpu: stop allocating dummy GTT nodes
Now that TTM is fixed up we can finally stop that nonsense.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c | 104 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 18 +++-
2 files changed, 42 insertions(+), 80 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
index 2c20d23d62d1..62cf4fbd803a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
@@ -150,60 +150,7 @@ static int amdgpu_gtt_mgr_fini(struct ttm_mem_type_manager
*man)
*/
bool amdgpu_gtt_mgr_has_gart_addr(struct ttm_mem_reg *mem) {
- struct amdgpu_gtt_node *node = mem->mm_node;
-
- return (node->node.start != AMDGPU_BO_INVALID_OFFSET);
-}
-
-/**
- * amdgpu_gtt_mgr_alloc - allocate new ranges
- *
- * @man: TTM memory type manager
- * @tbo: TTM BO we need this range for
- * @place: placement flags and restrictions
- * @mem: the resulting mem object
- *
- * Allocate the address space for a node.
- */
-static int amdgpu_gtt_mgr_alloc(struct ttm_mem_type_manager *man,
- struct ttm_buffer_object *tbo,
- const struct ttm_place *place,
- struct ttm_mem_reg *mem)
-{
- struct amdgpu_device *adev = amdgpu_ttm_adev(man->bdev);
- struct amdgpu_gtt_mgr *mgr = man->priv;
- struct amdgpu_gtt_node *node = mem->mm_node;
- enum drm_mm_insert_mode mode;
- unsigned long fpfn, lpfn;
- int r;
-
- if (amdgpu_gtt_mgr_has_gart_addr(mem))
- return 0;
-
- if (place)
- fpfn = place->fpfn;
- else
- fpfn = 0;
-
- if (place && place->lpfn)
- lpfn = place->lpfn;
- else
- lpfn = adev->gart.num_cpu_pages;
-
- mode = DRM_MM_INSERT_BEST;
- if (place && place->flags & TTM_PL_FLAG_TOPDOWN)
- mode = DRM_MM_INSERT_HIGH;
-
- spin_lock(&mgr->lock);
- r = drm_mm_insert_node_in_range(&mgr->mm, &node->node, mem->num_pages,
- mem->page_alignment, 0, fpfn, lpfn,
- mode);
- spin_unlock(&mgr->lock);
-
- if (!r)
- mem->start = node->node.start;
-
- return r;
+ return mem->mm_node != NULL;
}
/**
@@ -234,29 +181,37 @@ static int amdgpu_gtt_mgr_new(struct ttm_mem_type_manager
*man,
atomic64_sub(mem->num_pages, &mgr->available);
spin_unlock(&mgr->lock);
+ if (!place->lpfn) {
+ mem->mm_node = NULL;
+ mem->start = AMDGPU_BO_INVALID_OFFSET;
+ return 0;
+ }
+
node = kzalloc(sizeof(*node), GFP_KERNEL);
if (!node) {
r = -ENOMEM;
goto err_out;
}
- node->node.start = AMDGPU_BO_INVALID_OFFSET;
- node->node.size = mem->num_pages;
node->tbo = tbo;
- mem->mm_node = node;
- if (place->fpfn || place->lpfn || place->flags & TTM_PL_FLAG_TOPDOWN) {
- r = amdgpu_gtt_mgr_alloc(man, tbo, place, mem);
- if (unlikely(r)) {
- kfree(node);
- mem->mm_node = NULL;
- goto err_out;
- }
- } else {
- mem->start = node->node.start;
- }
+ spin_lock(&mgr->lock);
+ r = drm_mm_insert_node_in_range(&mgr->mm, &node->node, mem->num_pages,
+ mem->page_alignment, 0, place->fpfn,
+ place->lpfn, DRM_MM_INSERT_BEST);
+ spin_unlock(&mgr->lock);
+
+ if (unlikely(r))
+ goto err_free;
+
+ mem->mm_node = node;
+ mem->start = node->node.start;
return 0;
+
+err_free:
+ kfree(node);
+
err_out:
atomic64_add(mem->num_pages, &mgr->available);
@@ -279,17 +234,14 @@ static void amdgpu_gtt_mgr_del(struct
ttm_mem_type_manager *man,
struct amdgpu_gtt_mgr *mgr = man->priv;
struct amdgpu_gtt_node *node = mem->mm_node;
- if (!node)
- return;
-
- spin_lock(&mgr->lock);
- if (node->node.start != AMDGPU_BO_INVALID_OFFSET)
+ if (node) {
+ spin_lock(&mgr->lock);
drm_mm_remove_node(&node->node);
- spin_unlock(&mgr->lock);
- atomic64_add(mem->num_pages, &mgr->available);
+ spin_unlock(&mgr->lock);
+ kfree(node);
+ }
- kfree(node);
- mem->mm_node = NULL;
+ atomic64_add(mem->num_pages, &mgr->available);
}
Looks fine to me, nitpick: Should we update the docu
[PATCH 0/6] drm/ast: Managed MM
This is the second patchset for converting ast to managed DRM interfaces.
This one addresses memory management. There will be another, final round
of patches for converting DRM device structures as well.
Patch #1 introduces managed initialization for VRAM MM. Other drivers
using the VRAM helpers should be converted to this at some point.
Patches #2 to #4 do some preparation that make ast look slightly nicer.
Patch #5 fixes a long-standing bug that I found as part of the rework.
Posting the GPU requires information about the installed DRAM. So the DRAM
detection has to run before the GPU-posting code. This got reversed by a
fix in v4.11. The patch restores the original correct order of these
operations. As the GPU is usually posted by the VGA BIOS, the problem might
not have shown up in practice.
With all the cleanups in place, patch #6 switches memory management to
mnaged interfaces.
Tested on AST2100 HW.
Thomas Zimmermann (6):
drm/vram-helper: Managed vram helpers
drm/ast: Rename ast_ttm.c to ast_mm.c
drm/ast: Use managed VRAM-helper initialization
drm/ast: Move VRAM size detection to ast_mm.c
drm/ast: Initialize DRAM type before posting GPU
drm/ast: Use managed MM initialization
drivers/gpu/drm/ast/Makefile| 2 +-
drivers/gpu/drm/ast/ast_drv.h | 2 -
drivers/gpu/drm/ast/ast_main.c | 45 ++---
drivers/gpu/drm/ast/{ast_ttm.c => ast_mm.c} | 73 -
drivers/gpu/drm/drm_gem_vram_helper.c | 68 ++-
include/drm/drm_gem_vram_helper.h | 4 ++
6 files changed, 118 insertions(+), 76 deletions(-)
rename drivers/gpu/drm/ast/{ast_ttm.c => ast_mm.c} (64%)
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/6] drm/ast: Move VRAM size detection to ast_mm.c
VRAM size detection is only relevant to the memory management. Move
the code into ast_mm.c.
While at it, rename the function to ast_get_vram_size(). The function
argument's type is now struct ast_private. The result is stored in a
local variable and not in struct ast_private any longer.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/ast/ast_drv.h | 1 -
drivers/gpu/drm/ast/ast_main.c | 38 ++--
drivers/gpu/drm/ast/ast_mm.c | 45 +-
3 files changed, 46 insertions(+), 38 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_drv.h b/drivers/gpu/drm/ast/ast_drv.h
index c8c442e9efdc..9a770e5b36d1 100644
--- a/drivers/gpu/drm/ast/ast_drv.h
+++ b/drivers/gpu/drm/ast/ast_drv.h
@@ -110,7 +110,6 @@ struct ast_private {
uint32_t dram_bus_width;
uint32_t dram_type;
uint32_t mclk;
- uint32_t vram_size;
int fb_mtrr;
diff --git a/drivers/gpu/drm/ast/ast_main.c b/drivers/gpu/drm/ast/ast_main.c
index 860a43a64b31..b162cc82204d 100644
--- a/drivers/gpu/drm/ast/ast_main.c
+++ b/drivers/gpu/drm/ast/ast_main.c
@@ -378,38 +378,6 @@ static int ast_get_dram_info(struct drm_device *dev)
return 0;
}
-static u32 ast_get_vram_info(struct drm_device *dev)
-{
- struct ast_private *ast = to_ast_private(dev);
- u8 jreg;
- u32 vram_size;
- ast_open_key(ast);
-
- vram_size = AST_VIDMEM_DEFAULT_SIZE;
- jreg = ast_get_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xaa, 0xff);
- switch (jreg & 3) {
- case 0: vram_size = AST_VIDMEM_SIZE_8M; break;
- case 1: vram_size = AST_VIDMEM_SIZE_16M; break;
- case 2: vram_size = AST_VIDMEM_SIZE_32M; break;
- case 3: vram_size = AST_VIDMEM_SIZE_64M; break;
- }
-
- jreg = ast_get_index_reg_mask(ast, AST_IO_CRTC_PORT, 0x99, 0xff);
- switch (jreg & 0x03) {
- case 1:
- vram_size -= 0x10;
- break;
- case 2:
- vram_size -= 0x20;
- break;
- case 3:
- vram_size -= 0x40;
- break;
- }
-
- return vram_size;
-}
-
int ast_driver_load(struct drm_device *dev, unsigned long flags)
{
struct ast_private *ast;
@@ -456,10 +424,8 @@ int ast_driver_load(struct drm_device *dev, unsigned long
flags)
ret = ast_get_dram_info(dev);
if (ret)
goto out_free;
- ast->vram_size = ast_get_vram_info(dev);
- drm_info(dev, "dram MCLK=%u Mhz type=%d bus_width=%d size=%08x\n",
-ast->mclk, ast->dram_type,
-ast->dram_bus_width, ast->vram_size);
+ drm_info(dev, "dram MCLK=%u Mhz type=%d bus_width=%d\n",
+ast->mclk, ast->dram_type, ast->dram_bus_width);
ret = ast_mm_init(ast);
if (ret)
diff --git a/drivers/gpu/drm/ast/ast_mm.c b/drivers/gpu/drm/ast/ast_mm.c
index c0bbcfed9c43..4cf30bf6414a 100644
--- a/drivers/gpu/drm/ast/ast_mm.c
+++ b/drivers/gpu/drm/ast/ast_mm.c
@@ -33,14 +33,57 @@
#include "ast_drv.h"
+static u32 ast_get_vram_size(struct ast_private *ast)
+{
+ u8 jreg;
+ u32 vram_size;
+
+ ast_open_key(ast);
+
+ vram_size = AST_VIDMEM_DEFAULT_SIZE;
+ jreg = ast_get_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xaa, 0xff);
+ switch (jreg & 3) {
+ case 0:
+ vram_size = AST_VIDMEM_SIZE_8M;
+ break;
+ case 1:
+ vram_size = AST_VIDMEM_SIZE_16M;
+ break;
+ case 2:
+ vram_size = AST_VIDMEM_SIZE_32M;
+ break;
+ case 3:
+ vram_size = AST_VIDMEM_SIZE_64M;
+ break;
+ }
+
+ jreg = ast_get_index_reg_mask(ast, AST_IO_CRTC_PORT, 0x99, 0xff);
+ switch (jreg & 0x03) {
+ case 1:
+ vram_size -= 0x10;
+ break;
+ case 2:
+ vram_size -= 0x20;
+ break;
+ case 3:
+ vram_size -= 0x40;
+ break;
+ }
+
+ return vram_size;
+}
+
int ast_mm_init(struct ast_private *ast)
{
struct drm_vram_mm *vmm;
+ u32 vram_size;
int ret;
struct drm_device *dev = ast->dev;
+ vram_size = ast_get_vram_size(ast);
+
vmm = drmm_vram_helper_alloc_mm(dev, pci_resource_start(dev->pdev, 0),
- ast->vram_size);
+ vram_size);
if (IS_ERR(vmm)) {
ret = PTR_ERR(vmm);
drm_err(dev, "Error initializing VRAM MM; %d\n", ret);
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/6] drm/ast: Initialize DRAM type before posting GPU
Posting the GPU requires the correct DRAM type to be stored in
struct ast_private. Therefore first initialize the DRAM info and
then post the GPU. This restores the original order of instructions
in this function.
Signed-off-by: Thomas Zimmermann
Fixes: bad09da6deab ("drm/ast: Fixed vram size incorrect issue on POWER")
Cc: Joel Stanley
Cc: Y.C. Chen
Cc: Benjamin Herrenschmidt
Cc: Dave Airlie
Cc: Thomas Zimmermann
Cc: Gerd Hoffmann
Cc: Daniel Vetter
Cc: Sam Ravnborg
Cc: Emil Velikov
Cc: "Y.C. Chen"
Cc: # v4.11+
---
drivers/gpu/drm/ast/ast_main.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_main.c b/drivers/gpu/drm/ast/ast_main.c
index b162cc82204d..87e5baded2a7 100644
--- a/drivers/gpu/drm/ast/ast_main.c
+++ b/drivers/gpu/drm/ast/ast_main.c
@@ -418,15 +418,15 @@ int ast_driver_load(struct drm_device *dev, unsigned long
flags)
ast_detect_chip(dev, &need_post);
- if (need_post)
- ast_post_gpu(dev);
-
ret = ast_get_dram_info(dev);
if (ret)
goto out_free;
drm_info(dev, "dram MCLK=%u Mhz type=%d bus_width=%d\n",
ast->mclk, ast->dram_type, ast->dram_bus_width);
+ if (need_post)
+ ast_post_gpu(dev);
+
ret = ast_mm_init(ast);
if (ret)
goto out_free;
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/6] drm/ast: Rename ast_ttm.c to ast_mm.c
Although built upon TTM, the ast driver's VRAM MM helper does not
expose TTM to its users. Rename the related ast file to ast_mm.c.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/ast/Makefile| 2 +-
drivers/gpu/drm/ast/{ast_ttm.c => ast_mm.c} | 0
2 files changed, 1 insertion(+), 1 deletion(-)
rename drivers/gpu/drm/ast/{ast_ttm.c => ast_mm.c} (100%)
diff --git a/drivers/gpu/drm/ast/Makefile b/drivers/gpu/drm/ast/Makefile
index 6a5b3b247316..2265a8a624dd 100644
--- a/drivers/gpu/drm/ast/Makefile
+++ b/drivers/gpu/drm/ast/Makefile
@@ -3,7 +3,7 @@
# Makefile for the drm device driver. This driver provides support for the
# Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
-ast-y := ast_cursor.o ast_drv.o ast_main.o ast_mode.o ast_ttm.o ast_post.o \
+ast-y := ast_cursor.o ast_drv.o ast_main.o ast_mm.o ast_mode.o ast_post.o \
ast_dp501.o
obj-$(CONFIG_DRM_AST) := ast.o
diff --git a/drivers/gpu/drm/ast/ast_ttm.c b/drivers/gpu/drm/ast/ast_mm.c
similarity index 100%
rename from drivers/gpu/drm/ast/ast_ttm.c
rename to drivers/gpu/drm/ast/ast_mm.c
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 6/6] drm/ast: Use managed MM initialization
Cleaning up ast's MM code with ast_mm_fini() resets the write-combine
flags on the VRAM I/O memory. Drop ast_mm_fini() in favor of an auto-
release callback. Releasing the device also executes the callback.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/ast/ast_drv.h | 1 -
drivers/gpu/drm/ast/ast_main.c | 1 -
drivers/gpu/drm/ast/ast_mm.c | 23 ---
3 files changed, 12 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_drv.h b/drivers/gpu/drm/ast/ast_drv.h
index 9a770e5b36d1..e3a264ac7ee2 100644
--- a/drivers/gpu/drm/ast/ast_drv.h
+++ b/drivers/gpu/drm/ast/ast_drv.h
@@ -291,7 +291,6 @@ int ast_mode_config_init(struct ast_private *ast);
#define AST_MM_ALIGN_MASK ((1 << AST_MM_ALIGN_SHIFT) - 1)
int ast_mm_init(struct ast_private *ast);
-void ast_mm_fini(struct ast_private *ast);
/* ast post */
void ast_enable_vga(struct drm_device *dev);
diff --git a/drivers/gpu/drm/ast/ast_main.c b/drivers/gpu/drm/ast/ast_main.c
index 87e5baded2a7..dd12b55d57a2 100644
--- a/drivers/gpu/drm/ast/ast_main.c
+++ b/drivers/gpu/drm/ast/ast_main.c
@@ -452,6 +452,5 @@ void ast_driver_unload(struct drm_device *dev)
ast_release_firmware(dev);
kfree(ast->dp501_fw_addr);
- ast_mm_fini(ast);
kfree(ast);
}
diff --git a/drivers/gpu/drm/ast/ast_mm.c b/drivers/gpu/drm/ast/ast_mm.c
index 4cf30bf6414a..52debea8d1c7 100644
--- a/drivers/gpu/drm/ast/ast_mm.c
+++ b/drivers/gpu/drm/ast/ast_mm.c
@@ -28,8 +28,9 @@
#include
-#include
#include
+#include
+#include
#include "ast_drv.h"
@@ -73,6 +74,15 @@ static u32 ast_get_vram_size(struct ast_private *ast)
return vram_size;
}
+static void ast_mm_release(struct drm_device *dev, void *ptr)
+{
+ struct ast_private *ast = to_ast_private(dev);
+
+ arch_phys_wc_del(ast->fb_mtrr);
+ arch_io_free_memtype_wc(pci_resource_start(dev->pdev, 0),
+ pci_resource_len(dev->pdev, 0));
+}
+
int ast_mm_init(struct ast_private *ast)
{
struct drm_vram_mm *vmm;
@@ -95,14 +105,5 @@ int ast_mm_init(struct ast_private *ast)
ast->fb_mtrr = arch_phys_wc_add(pci_resource_start(dev->pdev, 0),
pci_resource_len(dev->pdev, 0));
- return 0;
-}
-
-void ast_mm_fini(struct ast_private *ast)
-{
- struct drm_device *dev = ast->dev;
-
- arch_phys_wc_del(ast->fb_mtrr);
- arch_io_free_memtype_wc(pci_resource_start(dev->pdev, 0),
- pci_resource_len(dev->pdev, 0));
+ return drmm_add_action_or_reset(dev, ast_mm_release, NULL);
}
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/6] drm/ast: Use managed VRAM-helper initialization
As a first step to managed MM code in ast, switch over VRAM MM helpers.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/ast/ast_mm.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_mm.c b/drivers/gpu/drm/ast/ast_mm.c
index 9c3788a4c1c5..c0bbcfed9c43 100644
--- a/drivers/gpu/drm/ast/ast_mm.c
+++ b/drivers/gpu/drm/ast/ast_mm.c
@@ -39,9 +39,8 @@ int ast_mm_init(struct ast_private *ast)
int ret;
struct drm_device *dev = ast->dev;
- vmm = drm_vram_helper_alloc_mm(
- dev, pci_resource_start(dev->pdev, 0),
- ast->vram_size);
+ vmm = drmm_vram_helper_alloc_mm(dev, pci_resource_start(dev->pdev, 0),
+ ast->vram_size);
if (IS_ERR(vmm)) {
ret = PTR_ERR(vmm);
drm_err(dev, "Error initializing VRAM MM; %d\n", ret);
@@ -60,8 +59,6 @@ void ast_mm_fini(struct ast_private *ast)
{
struct drm_device *dev = ast->dev;
- drm_vram_helper_release_mm(dev);
-
arch_phys_wc_del(ast->fb_mtrr);
arch_io_free_memtype_wc(pci_resource_start(dev->pdev, 0),
pci_resource_len(dev->pdev, 0));
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/6] drm/vram-helper: Managed vram helpers
Calling drmm_vram_helper_alloc_mm() sets up a managed instance of
VRAM MM. Releasing the DRM device also frees the memory manager.
The patch also updates the DRM documentation for VRAM helpers. The
tutorial now only describes the new managed interface. The older
interfaces are deprecated and should not be used in new code.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_gem_vram_helper.c | 68 ---
include/drm/drm_gem_vram_helper.h | 4 ++
2 files changed, 55 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
b/drivers/gpu/drm/drm_gem_vram_helper.c
index ad096600d89f..af116999b193 100644
--- a/drivers/gpu/drm/drm_gem_vram_helper.c
+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -41,7 +42,7 @@ static const struct drm_gem_object_funcs
drm_gem_vram_object_funcs;
* left in VRAM, inactive GEM objects can be moved to system memory.
*
* The easiest way to use the VRAM helper library is to call
- * drm_vram_helper_alloc_mm(). The function allocates and initializes an
+ * drmm_vram_helper_alloc_mm(). The function allocates and initializes an
* instance of &struct drm_vram_mm in &struct drm_device.vram_mm . Use
* &DRM_GEM_VRAM_DRIVER to initialize &struct drm_driver and
* &DRM_VRAM_MM_FILE_OPERATIONS to initialize &struct file_operations;
@@ -69,7 +70,7 @@ static const struct drm_gem_object_funcs
drm_gem_vram_object_funcs;
* // setup device, vram base and size
* // ...
*
- * ret = drm_vram_helper_alloc_mm(dev, vram_base, vram_size);
+ * ret = drmm_vram_helper_alloc_mm(dev, vram_base, vram_size);
* if (ret)
* return ret;
* return 0;
@@ -81,20 +82,12 @@ static const struct drm_gem_object_funcs
drm_gem_vram_object_funcs;
* manages an area of video RAM with VRAM MM and provides GEM VRAM objects
* to userspace.
*
- * To clean up the VRAM memory management, call drm_vram_helper_release_mm()
- * in the driver's clean-up code.
+ * You don't have to clean up the instance of VRAM MM.
+ * drmm_vram_helper_alloc_mm() is a managed interface that installs a
+ * clean-up handler to run during the DRM device's release.
*
- * .. code-block:: c
- *
- * void fini_drm_driver()
- * {
- * struct drm_device *dev = ...;
- *
- * drm_vram_helper_release_mm(dev);
- * }
- *
- * For drawing or scanout operations, buffer object have to be pinned in video
- * RAM. Call drm_gem_vram_pin() with &DRM_GEM_VRAM_PL_FLAG_VRAM or
+ * For drawing or scanout operations, rsp. buffer objects have to be pinned
+ * in video RAM. Call drm_gem_vram_pin() with &DRM_GEM_VRAM_PL_FLAG_VRAM or
* &DRM_GEM_VRAM_PL_FLAG_SYSTEM to pin a buffer object in video RAM or system
* memory. Call drm_gem_vram_unpin() to release the pinned object afterwards.
*
@@ -1177,12 +1170,16 @@ static void drm_vram_mm_cleanup(struct drm_vram_mm *vmm)
*/
/**
- * drm_vram_helper_alloc_mm - Allocates a device's instance of \
- &struct drm_vram_mm
+ * drm_vram_helper_alloc_mm - Allocates a device's instance of
+ *&struct drm_vram_mm
* @dev: the DRM device
* @vram_base: the base address of the video memory
* @vram_size: the size of the video memory in bytes
*
+ * The driver is responsible to clean-up the VRAM manager during
+ * device cleanup by calling drm_vram_helper_release_mm(). Use
+ * drmm_vram_helper_alloc_mm() if possible.
+ *
* Returns:
* The new instance of &struct drm_vram_mm on success, or
* an ERR_PTR()-encoded errno code otherwise.
@@ -1228,6 +1225,43 @@ void drm_vram_helper_release_mm(struct drm_device *dev)
}
EXPORT_SYMBOL(drm_vram_helper_release_mm);
+static void drm_vram_mm_release(struct drm_device *dev, void *ptr)
+{
+ drm_vram_helper_release_mm(dev);
+}
+
+/**
+ * drmm_vram_helper_alloc_mm - Allocates a device's managed instance of
+ * &struct drm_vram_mm
+ * @dev: the DRM device
+ * @vram_base: the base address of the video memory
+ * @vram_size: the size of the video memory in bytes
+ *
+ * The returned instance of &struct drm_vram_mm is auto-managed and
+ * cleaned up as part of device cleanup.
+ *
+ * Returns:
+ * The new instance of &struct drm_vram_mm on success, or
+ * an ERR_PTR()-encoded errno code otherwise.
+ */
+struct drm_vram_mm *drmm_vram_helper_alloc_mm(struct drm_device *dev,
+ uint64_t vram_base,
+ size_t vram_size)
+{
+ struct drm_vram_mm *vram_mm;
+ int ret;
+
+ vram_mm = drm_vram_helper_alloc_mm(dev, vram_base, vram_size);
+ if (IS_ERR(vram_mm))
+ return vram_mm;
+ ret = drmm_add_action_or_reset(dev, drm_vram_mm_release, NULL);
+ if (ret)
+ return ERR_PTR(ret);
+
+ ret
Re: [PATCH] drm: imx: Fix occasional screen corruption on modeset.
Hi Martin,
On Tue, 2020-07-07 at 17:56 +0200, Martin Fuzzey wrote:
> When performing a modeset the atomic core calls
> ipu_crtc_atomic_disable() which switches off the DC and DI.
>
> When we immediately restart as in the modeset case this sometimes
> leads to corruption at the bottom of the screen looking like a mirror
> image of the top.
Could this be just a panel getting confused because the pixel clock is
disabled, or is there really an issue with the IPU? Have you tried just
keeping clk_di_pixel enabled in ipu_di_disable(), but continuing
to disable DI and DC?
> The exact reason isn't understood but it seems timing related.
>
> This was observed on i.MX6DL on a system that does 2 mode
> transitions on boot (fbcon->android boot animation->android homescreen)
> then no more during normal operation resulting in corruption
> about once every 10 boots that lasted for variable durations
> from a few seconds to several hours.
>
> Dumping the buffers confirmed that they were correct in memory,
> just the display was wrong.
>
> For tests the problem was reproduced systematically by forcing
> a full modeset every 10 frames even if when not required.
>
> Leaving the DC and DI on if the CRTC is staying on fixes this.
>
> Signed-off-by: Martin Fuzzey
> ---
> drivers/gpu/drm/imx/ipuv3-crtc.c | 11 +--
> 1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/imx/ipuv3-crtc.c
> b/drivers/gpu/drm/imx/ipuv3-crtc.c
> index 63c0284..9137b64 100644
> --- a/drivers/gpu/drm/imx/ipuv3-crtc.c
> +++ b/drivers/gpu/drm/imx/ipuv3-crtc.c
> @@ -84,8 +84,15 @@ static void ipu_crtc_atomic_disable(struct drm_crtc *crtc,
> struct ipu_crtc *ipu_crtc = to_ipu_crtc(crtc);
> struct ipu_soc *ipu = dev_get_drvdata(ipu_crtc->dev->parent);
>
> - ipu_dc_disable_channel(ipu_crtc->dc);
> - ipu_di_disable(ipu_crtc->di);
> + /*
> + * If we are just doing a modeset don't disable dc/di as that
> + * sometimes leads to corruption at the bottom of the screen
> + */
> + if (!crtc->state->active) {
> + ipu_dc_disable_channel(ipu_crtc->dc);
> + ipu_di_disable(ipu_crtc->di);
Just removing ipu_di_disable() leaks a clk_prepare_enable refcount on
the di->clk_di_pixel clock.
Also this is followed by an ipu_dc_disable(), which should remove the DC
module's clock if this is the only display. So the DC should be disabled
anyway.
> + }
> +
> /*
>* Planes must be disabled before DC clock is removed, as otherwise the
>* attached IDMACs will be left in undefined state, possibly hanging
regards
Philipp
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 5/6] drm/ast: Initialize DRAM type before posting GPU
On Wed, 2020-07-08 at 09:49 +0200, Thomas Zimmermann wrote:
> Posting the GPU requires the correct DRAM type to be stored in
> struct ast_private. Therefore first initialize the DRAM info and
> then post the GPU. This restores the original order of instructions
> in this function.
I no longer have access to the relevant test POWER systems,
however the patch looks good to me.
> Signed-off-by: Thomas Zimmermann
> Fixes: bad09da6deab ("drm/ast: Fixed vram size incorrect issue on
> POWER")
> Cc: Joel Stanley
> Cc: Y.C. Chen
Acked-by: Benjamin Herrenschmidt
> Cc: Dave Airlie
> Cc: Thomas Zimmermann
> Cc: Gerd Hoffmann
> Cc: Daniel Vetter
> Cc: Sam Ravnborg
> Cc: Emil Velikov
> Cc: "Y.C. Chen"
> Cc: # v4.11+
> ---
> drivers/gpu/drm/ast/ast_main.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/ast/ast_main.c
> b/drivers/gpu/drm/ast/ast_main.c
> index b162cc82204d..87e5baded2a7 100644
> --- a/drivers/gpu/drm/ast/ast_main.c
> +++ b/drivers/gpu/drm/ast/ast_main.c
> @@ -418,15 +418,15 @@ int ast_driver_load(struct drm_device *dev,
> unsigned long flags)
>
> ast_detect_chip(dev, &need_post);
>
> - if (need_post)
> - ast_post_gpu(dev);
> -
> ret = ast_get_dram_info(dev);
> if (ret)
> goto out_free;
> drm_info(dev, "dram MCLK=%u Mhz type=%d bus_width=%d\n",
>ast->mclk, ast->dram_type, ast->dram_bus_width);
>
> + if (need_post)
> + ast_post_gpu(dev);
> +
> ret = ast_mm_init(ast);
> if (ret)
> goto out_free;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/vgem: Do not allocate backing shmemfs file for an import dmabuf object
Am 07.07.20 um 20:35 schrieb Chris Wilson: Quoting lepton (2020-07-07 19:17:51) On Tue, Jul 7, 2020 at 10:20 AM Chris Wilson wrote: Quoting lepton (2020-07-07 18:05:21) On Tue, Jul 7, 2020 at 9:00 AM Chris Wilson wrote: If we assign obj->filp, we believe that the create vgem bo is native and allow direct operations like mmap() assuming it behaves as backed by a shmemfs inode. When imported from a dmabuf, the obj->pages are not always meaningful and the shmemfs backing store misleading. Note, that regular mmap access to a vgem bo is via the dumb buffer API, and that rejects attempts to mmap an imported dmabuf, What do you mean by "regular mmap access" here? It looks like vgem is using vgem_gem_dumb_map as .dumb_map_offset callback then it doesn't call drm_gem_dumb_map_offset As I too found out, and so had to correct my story telling. By regular mmap() access I mean mmap on the vgem bo [via the dumb buffer API] as opposed to mmap() via an exported dma-buf fd. I had to look at igt to see how it was being used. Now it seems your fix is to disable "regular mmap" on imported dma buf for vgem. I am not really a graphic guy, but then the api looks like: for a gem handle, user space has to guess to find out the way to mmap it. If user space guess wrong, then it will fail to mmap. Is this the expected way for people to handle gpu buffer? You either have a dumb buffer handle, or a dma-buf fd. If you have the handle, you have to use the dumb buffer API, there's no other way to mmap it. If you have the dma-buf fd, you should mmap it directly. Those two are clear. It's when you import the dma-buf into vgem and create a handle out of it, that's when the handle is no longer first class and certain uAPI [the dumb buffer API in particular] fail. It's not brilliant, as you say, it requires the user to remember the difference between the handles, but at the same time it does prevent them falling into coherency traps by forcing them to use the right driver to handle the object, and have to consider the additional ioctls that go along with that access. Yes, Chris is right. Mapping DMA-buf through the mmap() APIs of an importer is illegal. What we could maybe try to do is to redirect this mmap() API call on the importer to the exporter, but I'm pretty sure that the fs layer wouldn't like that without changes. Regards, Christian. -Chris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 15/25] drm/tilcdc: Use standard drm_atomic_helper_commit
On Wed, Jul 8, 2020 at 11:17 AM Jyri Sarha wrote:
>
> On 07/07/2020 23:12, Daniel Vetter wrote:
> > Gives us proper nonblocking support for free, and a pile of other
> > things. The tilcdc code is simply old enough that it was never
> > converted over, but was stuck forever with the copypasta from when it
> > was initially merged.
> >
> > The riskiest thing with this conversion is maybe that there's an issue
> > with the vblank handling or vblank event handling, which will upset
> > the modern commit support in atomic helpers. But from a cursory review
> > drm_crtc_vblank_on/off is called in the right places, and the event
> > handling also seems to exist (albeit with much hand-rolling and
> > probably some races, could perhaps be converted over to
> > drm_crtc_arm_vblank_event without any real loss).
> >
> > Motivated by me not having to hand-roll the dma-fence annotations for
> > this.
> >
> > Signed-off-by: Daniel Vetter
> > Cc: Jyri Sarha
> > Cc: Tomi Valkeinen
>
> I tried this out, but it is not working. Something breaks in the event
> handling and event reference counting. Unfortunately my vacation is
> pressing on, and I am not sure if I have time to debug the issue further
> before that.
Thanks a lot for testing, looks like tilcdc doesn't quite handle the
event stuff in all cases, which results in the direct warning in
hw_done, and then the refcount fallout in plane_destry_state (I think
at least, not entirely sure about whether that's really just
collateral damage or a 2nd bug).
I'll try to come up with something, enjoy your vacations meanwhile!
Cheers, Daniel
> Anyway, I have attached the boot log with the following WARN dumps:
>
> [ 12.203874] WARNING: CPU: 0 PID: 208 at
> drivers/gpu/drm/drm_atomic_helper.c:2329
> drm_atomic_helper_commit_hw_done+0x144/0x168 [drm_kms_helper]
>
> [ 12.217682] WARNING: CPU: 0 PID: 208 at
> drivers/gpu/drm/drm_atomic_helper.c:2329
> drm_atomic_helper_commit_hw_done+0x144/0x168 [drm_kms_helper]
>
> [ 232.156231] WARNING: CPU: 0 PID: 1315 at
> drivers/gpu/drm/drm_atomic_helper.c:2329
> drm_atomic_helper_commit_hw_done+0x144/0x168 [drm_kms_helper]
>
> [ 232.472068] WARNING: CPU: 0 PID: 1315 at lib/refcount.c:28
> __drm_atomic_helper_plane_destroy_state+0xd0/0xe0 [drm_kms_helper]
>
> [ 240.611129] WARNING: CPU: 0 PID: 1317 at
> drivers/gpu/drm/drm_atomic_helper.c:2329
> drm_atomic_helper_commit_hw_done+0x144/0x168 [drm_kms_helper]
>
>
> The first two came at boot time when setting up the fbconsole, the ones
> after that came when I tried to use kmstest[1]. The fbconsole came up,
> but nothing after that works.
>
> I am back from vacation in the beginning of august, so there may be some
> time before I can debug this further.
>
> Best regards,
> Jyri
>
>
>
> [1] https://github.com/tomba/kmsxx
>
> > ---
> > drivers/gpu/drm/tilcdc/tilcdc_drv.c | 47 +
> > 1 file changed, 1 insertion(+), 46 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
> > b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
> > index 0d74a6443263..4f5fc3e87383 100644
> > --- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
> > +++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
> > @@ -87,55 +87,10 @@ static int tilcdc_atomic_check(struct drm_device *dev,
> > return ret;
> > }
> >
> > -static int tilcdc_commit(struct drm_device *dev,
> > - struct drm_atomic_state *state,
> > - bool async)
> > -{
> > - int ret;
> > -
> > - ret = drm_atomic_helper_prepare_planes(dev, state);
> > - if (ret)
> > - return ret;
> > -
> > - ret = drm_atomic_helper_swap_state(state, true);
> > - if (ret) {
> > - drm_atomic_helper_cleanup_planes(dev, state);
> > - return ret;
> > - }
> > -
> > - /*
> > - * Everything below can be run asynchronously without the need to grab
> > - * any modeset locks at all under one condition: It must be guaranteed
> > - * that the asynchronous work has either been cancelled (if the driver
> > - * supports it, which at least requires that the framebuffers get
> > - * cleaned up with drm_atomic_helper_cleanup_planes()) or completed
> > - * before the new state gets committed on the software side with
> > - * drm_atomic_helper_swap_state().
> > - *
> > - * This scheme allows new atomic state updates to be prepared and
> > - * checked in parallel to the asynchronous completion of the previous
> > - * update. Which is important since compositors need to figure out the
> > - * composition of the next frame right after having submitted the
> > - * current layout.
> > - */
> > -
> > - drm_atomic_helper_commit_modeset_disables(dev, state);
> > -
> > - drm_atomic_helper_commit_planes(dev, state, 0);
> > -
> > - drm_atomic_helper_commit_modeset_enables(dev, state);
> >
Re: [RFC PATCH v2 0/3] RDMA: add dma-buf support
Am 07.07.20 um 23:58 schrieb Xiong, Jianxin: -Original Message- From: Christian König Am 03.07.20 um 15:14 schrieb Jason Gunthorpe: On Fri, Jul 03, 2020 at 02:52:03PM +0200, Daniel Vetter wrote: So maybe I'm just totally confused about the rdma model. I thought: - you bind a pile of memory for various transactions, that might happen whenever. Kernel driver doesn't have much if any insight into when memory isn't needed anymore. I think in the rdma world that's called registering memory, but not sure. Sure, but once registered the memory is able to be used at any moment with no visibilty from the kernel. Unlike GPU the transactions that trigger memory access do not go through the kernel - so there is no ability to interrupt a command flow and fiddle with mappings. This is the same for GPUs with user space queues as well. But we can still say for a process if that this process is using a DMA-buf which is moved out and so can't run any more unless the DMA-buf is accessible again. In other words you somehow need to make sure that the hardware is not accessing a piece of memory any more when you want to move it. While a process can be easily suspended, there is no way to tell the RDMA NIC not to process posted work requests that use specific memory regions (or with any other conditions). So far it appears to me that DMA-buf dynamic mapping for RDMA is only viable with ODP support. For NICs without ODP, a way to allow pinning the device memory is still needed. And that's exactly the reason why I introduced explicit pin()/unpin() functions into the DMA-buf API: https://elixir.bootlin.com/linux/latest/source/drivers/dma-buf/dma-buf.c#L811 It's just that at least our devices drivers currently prevent P2P with pinned DMA-buf's for two main reasons: a) To prevent deny of service attacks because P2P BARs are a rather rare resource. b) To prevent failures in configuration where P2P is not always possible between all devices which want to access a buffer. Regards, Christian. Jianxin Christian. Jason ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/ttm: further cleanup ttm_mem_reg handling
Am 07.07.20 um 21:16 schrieb Chauhan, Madhav:
[AMD Public Use]
-Original Message-
From: amd-gfx On Behalf Of Christian
König
Sent: Monday, July 6, 2020 11:18 PM
To: amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
Subject: [PATCH 1/2] drm/ttm: further cleanup ttm_mem_reg handling
Stop touching the backend private pointer alltogether and make sure we never
put the same mem twice by.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c| 46 +++--
include/drm/ttm/ttm_bo_driver.h | 2 --
2 files changed, 26 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c index
0c13fe96c7e3..7be36b9996ed 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -312,7 +312,6 @@ static int ttm_bo_handle_move_mem(struct ttm_buffer_object
*bo,
if (bdev->driver->move_notify)
bdev->driver->move_notify(bo, evict, mem);
bo->mem = *mem;
- mem->mm_node = NULL;
goto moved;
}
}
@@ -616,7 +615,6 @@ static void ttm_bo_release(struct kref *kref)
ttm_bo_cleanup_memtype_use(bo);
dma_resv_unlock(bo->base.resv);
- BUG_ON(bo->mem.mm_node != NULL);
atomic_dec(&ttm_bo_glob.bo_count);
dma_fence_put(bo->moving);
if (!ttm_bo_uses_embedded_gem_object(bo))
@@ -843,12 +841,29 @@ static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
return ret;
}
+static int ttm_bo_mem_get(struct ttm_buffer_object *bo,
+ const struct ttm_place *place,
+ struct ttm_mem_reg *mem)
+{
+ struct ttm_mem_type_manager *man = &bo->bdev->man[mem->mem_type];
+
+ mem->mm_node = NULL;
+ if (!man->func || !man->func->get_node)
+ return 0;
+
+ return man->func->get_node(man, bo, place, mem); }
+
Should not we export this as a symbol, so that it can be used similar to
ttm_bo_mem_put in drm drivers??
No, it's a well known design problem of TTM that the exported counter
part of ttm_bo_mem_put() is ttm_bo_mem_space().
I have it on my TODO list to fix this, but that needs a bigger change.
Regards,
Christian.
Regards,
Madhav
void ttm_bo_mem_put(struct ttm_buffer_object *bo, struct ttm_mem_reg *mem) {
struct ttm_mem_type_manager *man = &bo->bdev->man[mem->mem_type];
- if (mem->mm_node)
- (*man->func->put_node)(man, mem);
+ if (!man->func || !man->func->put_node)
+ return;
+
+ man->func->put_node(man, mem);
+ mem->mm_node = NULL;
+ mem->mem_type = TTM_PL_SYSTEM;
}
EXPORT_SYMBOL(ttm_bo_mem_put);
@@ -902,7 +917,7 @@ static int ttm_bo_mem_force_space(struct ttm_buffer_object *bo,
ticket = dma_resv_locking_ctx(bo->base.resv);
do {
- ret = (*man->func->get_node)(man, bo, place, mem);
+ ret = ttm_bo_mem_get(bo, place, mem);
if (likely(!ret))
break;
if (unlikely(ret != -ENOSPC))
@@ -1032,7 +1047,6 @@ int ttm_bo_mem_space(struct ttm_buffer_object *bo,
if (unlikely(ret))
return ret;
- mem->mm_node = NULL;
for (i = 0; i < placement->num_placement; ++i) {
const struct ttm_place *place = &placement->placement[i];
struct ttm_mem_type_manager *man;
@@ -1044,20 +1058,16 @@ int ttm_bo_mem_space(struct ttm_buffer_object *bo,
goto error;
type_found = true;
- mem->mm_node = NULL;
- if (mem->mem_type == TTM_PL_SYSTEM)
- return 0;
-
- man = &bdev->man[mem->mem_type];
- ret = (*man->func->get_node)(man, bo, place, mem);
+ ret = ttm_bo_mem_get(bo, place, mem);
if (ret == -ENOSPC)
continue;
if (unlikely(ret))
goto error;
+ man = &bdev->man[mem->mem_type];
ret = ttm_bo_add_move_fence(bo, man, mem, ctx->no_wait_gpu);
if (unlikely(ret)) {
- (*man->func->put_node)(man, mem);
+ ttm_bo_mem_put(bo, mem);
if (ret == -EBUSY)
continue;
@@ -1076,12 +1086,8 @@ int ttm_bo_mem_space(struct ttm_buffer_object *bo,
goto error;
type_found = true;
- mem->mm_node = NULL;
- if (mem->mem_type == TTM_PL_SYSTEM)
- return 0;
-
ret = ttm_bo_mem_force_space(bo, place, mem, ctx);
- if (ret == 0 && mem->mm_node)
+ if (likely(!ret))
return 0;
if (ret && ret != -EBUSY)
@@ -1129,7 +1135,7 @@ static int ttm_bo_move_buffer(struct ttm_buffer_object
*bo,
[PATCH] drm/tilcdc: Use standard drm_atomic_helper_commit
Gives us proper nonblocking support for free, and a pile of other
things. The tilcdc code is simply old enough that it was never
converted over, but was stuck forever with the copypasta from when it
was initially merged.
The riskiest thing with this conversion is maybe that there's an issue
with the vblank handling or vblank event handling, which will upset
the modern commit support in atomic helpers. But from a cursory review
drm_crtc_vblank_on/off is called in the right places, and the event
handling also seems to exist (albeit with much hand-rolling and
probably some races, could perhaps be converted over to
drm_crtc_arm_vblank_event without any real loss).
Motivated by me not having to hand-roll the dma-fence annotations for
this.
v2: Clear out crtc_state->event when we're handling the event, to
avoid upsetting the helpers (reported by Jyri).
Signed-off-by: Daniel Vetter
Cc: Jyri Sarha
Cc: Tomi Valkeinen
--
I'm not really sure whether the event handling is correct for when a
crtc gets disabled. dpms off or similar would be a good test, assuming
this patch here fixes the first issue.
-Daniel
---
drivers/gpu/drm/tilcdc/tilcdc_drv.c | 47 +--
drivers/gpu/drm/tilcdc/tilcdc_plane.c | 8 +++--
2 files changed, 6 insertions(+), 49 deletions(-)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
index 0d74a6443263..4f5fc3e87383 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
@@ -87,55 +87,10 @@ static int tilcdc_atomic_check(struct drm_device *dev,
return ret;
}
-static int tilcdc_commit(struct drm_device *dev,
- struct drm_atomic_state *state,
- bool async)
-{
- int ret;
-
- ret = drm_atomic_helper_prepare_planes(dev, state);
- if (ret)
- return ret;
-
- ret = drm_atomic_helper_swap_state(state, true);
- if (ret) {
- drm_atomic_helper_cleanup_planes(dev, state);
- return ret;
- }
-
- /*
-* Everything below can be run asynchronously without the need to grab
-* any modeset locks at all under one condition: It must be guaranteed
-* that the asynchronous work has either been cancelled (if the driver
-* supports it, which at least requires that the framebuffers get
-* cleaned up with drm_atomic_helper_cleanup_planes()) or completed
-* before the new state gets committed on the software side with
-* drm_atomic_helper_swap_state().
-*
-* This scheme allows new atomic state updates to be prepared and
-* checked in parallel to the asynchronous completion of the previous
-* update. Which is important since compositors need to figure out the
-* composition of the next frame right after having submitted the
-* current layout.
-*/
-
- drm_atomic_helper_commit_modeset_disables(dev, state);
-
- drm_atomic_helper_commit_planes(dev, state, 0);
-
- drm_atomic_helper_commit_modeset_enables(dev, state);
-
- drm_atomic_helper_wait_for_vblanks(dev, state);
-
- drm_atomic_helper_cleanup_planes(dev, state);
-
- return 0;
-}
-
static const struct drm_mode_config_funcs mode_config_funcs = {
.fb_create = drm_gem_fb_create,
.atomic_check = tilcdc_atomic_check,
- .atomic_commit = tilcdc_commit,
+ .atomic_commit = drm_atomic_helper_commit,
};
static void modeset_init(struct drm_device *dev)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_plane.c
b/drivers/gpu/drm/tilcdc/tilcdc_plane.c
index 0d09b31ae759..2f681a713815 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_plane.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_plane.c
@@ -83,9 +83,11 @@ static void tilcdc_plane_atomic_update(struct drm_plane
*plane,
if (WARN_ON(!state->fb || !state->crtc->state))
return;
- tilcdc_crtc_update_fb(state->crtc,
- state->fb,
- state->crtc->state->event);
+ if (tilcdc_crtc_update_fb(state->crtc,
+ state->fb,
+ state->crtc->state->event) == 0) {
+ state->crtc->state->event = NULL;
+ }
}
static const struct drm_plane_helper_funcs plane_helper_funcs = {
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/amdgpu: stop allocating dummy GTT nodes
Am 08.07.20 um 09:35 schrieb Chauhan, Madhav:
[AMD Public Use]
-Original Message-
From: amd-gfx On Behalf Of Christian
König
Sent: Monday, July 6, 2020 11:18 PM
To: amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
Subject: [PATCH 2/2] drm/amdgpu: stop allocating dummy GTT nodes
Now that TTM is fixed up we can finally stop that nonsense.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c | 104 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 18 +++-
2 files changed, 42 insertions(+), 80 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
index 2c20d23d62d1..62cf4fbd803a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
@@ -150,60 +150,7 @@ static int amdgpu_gtt_mgr_fini(struct ttm_mem_type_manager
*man)
*/
bool amdgpu_gtt_mgr_has_gart_addr(struct ttm_mem_reg *mem) {
- struct amdgpu_gtt_node *node = mem->mm_node;
-
- return (node->node.start != AMDGPU_BO_INVALID_OFFSET);
-}
-
-/**
- * amdgpu_gtt_mgr_alloc - allocate new ranges
- *
- * @man: TTM memory type manager
- * @tbo: TTM BO we need this range for
- * @place: placement flags and restrictions
- * @mem: the resulting mem object
- *
- * Allocate the address space for a node.
- */
-static int amdgpu_gtt_mgr_alloc(struct ttm_mem_type_manager *man,
- struct ttm_buffer_object *tbo,
- const struct ttm_place *place,
- struct ttm_mem_reg *mem)
-{
- struct amdgpu_device *adev = amdgpu_ttm_adev(man->bdev);
- struct amdgpu_gtt_mgr *mgr = man->priv;
- struct amdgpu_gtt_node *node = mem->mm_node;
- enum drm_mm_insert_mode mode;
- unsigned long fpfn, lpfn;
- int r;
-
- if (amdgpu_gtt_mgr_has_gart_addr(mem))
- return 0;
-
- if (place)
- fpfn = place->fpfn;
- else
- fpfn = 0;
-
- if (place && place->lpfn)
- lpfn = place->lpfn;
- else
- lpfn = adev->gart.num_cpu_pages;
-
- mode = DRM_MM_INSERT_BEST;
- if (place && place->flags & TTM_PL_FLAG_TOPDOWN)
- mode = DRM_MM_INSERT_HIGH;
-
- spin_lock(&mgr->lock);
- r = drm_mm_insert_node_in_range(&mgr->mm, &node->node, mem->num_pages,
- mem->page_alignment, 0, fpfn, lpfn,
- mode);
- spin_unlock(&mgr->lock);
-
- if (!r)
- mem->start = node->node.start;
-
- return r;
+ return mem->mm_node != NULL;
}
/**
@@ -234,29 +181,37 @@ static int amdgpu_gtt_mgr_new(struct ttm_mem_type_manager
*man,
atomic64_sub(mem->num_pages, &mgr->available);
spin_unlock(&mgr->lock);
+ if (!place->lpfn) {
+ mem->mm_node = NULL;
+ mem->start = AMDGPU_BO_INVALID_OFFSET;
+ return 0;
+ }
+
node = kzalloc(sizeof(*node), GFP_KERNEL);
if (!node) {
r = -ENOMEM;
goto err_out;
}
- node->node.start = AMDGPU_BO_INVALID_OFFSET;
- node->node.size = mem->num_pages;
node->tbo = tbo;
- mem->mm_node = node;
- if (place->fpfn || place->lpfn || place->flags & TTM_PL_FLAG_TOPDOWN) {
- r = amdgpu_gtt_mgr_alloc(man, tbo, place, mem);
- if (unlikely(r)) {
- kfree(node);
- mem->mm_node = NULL;
- goto err_out;
- }
- } else {
- mem->start = node->node.start;
- }
+ spin_lock(&mgr->lock);
+ r = drm_mm_insert_node_in_range(&mgr->mm, &node->node, mem->num_pages,
+ mem->page_alignment, 0, place->fpfn,
+ place->lpfn, DRM_MM_INSERT_BEST);
+ spin_unlock(&mgr->lock);
+
+ if (unlikely(r))
+ goto err_free;
+
+ mem->mm_node = node;
+ mem->start = node->node.start;
return 0;
+
+err_free:
+ kfree(node);
+
err_out:
atomic64_add(mem->num_pages, &mgr->available);
@@ -279,17 +234,14 @@ static void amdgpu_gtt_mgr_del(struct ttm_mem_type_manager *man,
struct amdgpu_gtt_mgr *mgr = man->priv;
struct amdgpu_gtt_node *node = mem->mm_node;
- if (!node)
- return;
-
- spin_lock(&mgr->lock);
- if (node->node.start != AMDGPU_BO_INVALID_OFFSET)
+ if (node) {
+ spin_lock(&mgr->lock);
drm_mm_remove_node(&node->node);
- spin_unlock(&mgr->lock);
- atomic64_add(mem->num_pages, &mgr->available);
+ spin_unlock(&mgr->lock);
+ kfree(node);
+ }
- kfree(node);
- mem->mm_node = NULL;
+ atomic64_add(mem->num_pages, &mgr->available);
}
Looks fine to
Re: [RFC PATCH v2 0/3] RDMA: add dma-buf support
On Wed, Jul 08, 2020 at 11:38:31AM +0200, Christian König wrote: > Am 07.07.20 um 23:58 schrieb Xiong, Jianxin: > > > -Original Message- > > > From: Christian König > > > Am 03.07.20 um 15:14 schrieb Jason Gunthorpe: > > > > On Fri, Jul 03, 2020 at 02:52:03PM +0200, Daniel Vetter wrote: > > > > > > > > > So maybe I'm just totally confused about the rdma model. I thought: > > > > > - you bind a pile of memory for various transactions, that might > > > > > happen whenever. Kernel driver doesn't have much if any insight into > > > > > when memory isn't needed anymore. I think in the rdma world that's > > > > > called registering memory, but not sure. > > > > Sure, but once registered the memory is able to be used at any moment > > > > with no visibilty from the kernel. > > > > > > > > Unlike GPU the transactions that trigger memory access do not go > > > > through the kernel - so there is no ability to interrupt a command > > > > flow and fiddle with mappings. > > > This is the same for GPUs with user space queues as well. > > > > > > But we can still say for a process if that this process is using a > > > DMA-buf which is moved out and so can't run any more unless the DMA-buf is > > > accessible again. > > > > > > In other words you somehow need to make sure that the hardware is not > > > accessing a piece of memory any more when you want to move it. > > > > > While a process can be easily suspended, there is no way to tell the RDMA > > NIC not to process posted work requests that use specific memory regions > > (or with any other conditions). > > > > So far it appears to me that DMA-buf dynamic mapping for RDMA is only > > viable with ODP support. For NICs without ODP, a way to allow pinning the > > device memory is still needed. > > And that's exactly the reason why I introduced explicit pin()/unpin() > functions into the DMA-buf API: > https://elixir.bootlin.com/linux/latest/source/drivers/dma-buf/dma-buf.c#L811 > > It's just that at least our devices drivers currently prevent P2P with > pinned DMA-buf's for two main reasons: > > a) To prevent deny of service attacks because P2P BARs are a rather rare > resource. > > b) To prevent failures in configuration where P2P is not always possible > between all devices which want to access a buffer. So the above is more or less the question in the cover letter (which didn't make it to dri-devel). Can we somehow throw that limitation out, or is that simply not a good idea? Simply moving buffers to system memory when they're pinned does simplify a lot of headaches. For a specific custom built system we can avoid that maybe, but I think upstream is kinda a different thing. Cheers, Daniel > Regards, > Christian. > > > > > Jianxin > > > > > Christian. > > > > > > > Jason > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/stm: repair runtime power management
Le jeu. 2 juil. 2020 à 14:31, Philippe CORNU a écrit :
>
>
>
> On 2/29/20 11:16 PM, Marek Vasut wrote:
> > Add missing pm_runtime_get_sync() into ltdc_crtc_atomic_enable() to
> > match pm_runtime_put_sync() in ltdc_crtc_atomic_disable(), otherwise
> > the LTDC might suspend via runtime PM, disable clock, and then fail
> > to resume later on.
> >
> > The test which triggers it is roughly -- run qt5 application which
> > uses eglfs platform and etnaviv, stop the application, sleep for 15
> > minutes, run the application again. This leads to a timeout waiting
> > for vsync, because the LTDC has suspended, but did not resume.
> >
> > Fixes: 35ab6cfbf211 ("drm/stm: support runtime power management")
> > Signed-off-by: Marek Vasut
> > Cc: Yannick Fertré
> > Cc: Philippe Cornu
> > Cc: Benjamin Gaignard
> > Cc: Vincent Abriou
> > Cc: Maxime Coquelin
> > Cc: Alexandre Torgue
> > To: dri-devel@lists.freedesktop.org
> > Cc: linux-st...@st-md-mailman.stormreply.com
> > Cc: linux-arm-ker...@lists.infradead.org
> > ---
> > [ cut here ]
> > WARNING: CPU: 0 PID: 297 at drivers/gpu/drm/drm_atomic_helper.c:1494
> > drm_atomic_helper_wait_for_vblanks+0x1dc/0x200
> > [CRTC:35:crtc-0] vblank wait timed out
> > Modules linked in:
> > CPU: 0 PID: 297 Comm: QSGRenderThread Not tainted
> > 5.6.0-rc3-next-20200228-00010-g318bf0fc08ef #2
> > Hardware name: STM32 (Device Tree Support)
> > [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
> > [] (show_stack) from [] (dump_stack+0xb4/0xd0)
> > [] (dump_stack) from [] (__warn+0xd4/0xf0)
> > [] (__warn) from [] (warn_slowpath_fmt+0x78/0xa8)
> > [] (warn_slowpath_fmt) from []
> > (drm_atomic_helper_wait_for_vblanks+0x1dc/0x200)
> > [] (drm_atomic_helper_wait_for_vblanks) from []
> > (drm_atomic_helper_commit_tail+0
> > x50/0x60)
> > [] (drm_atomic_helper_commit_tail) from []
> > (commit_tail+0x12c/0x13c)
> > [] (commit_tail) from []
> > (drm_atomic_helper_commit+0xf4/0x100)
> > [] (drm_atomic_helper_commit) from []
> > (drm_atomic_helper_set_config+0x58/0x6c)
> > [] (drm_atomic_helper_set_config) from []
> > (drm_mode_setcrtc+0x450/0x550)
> > [] (drm_mode_setcrtc) from []
> > (drm_ioctl_kernel+0x90/0xe8)
> > [] (drm_ioctl_kernel) from [] (drm_ioctl+0x2e4/0x32c)
> > [] (drm_ioctl) from [] (vfs_ioctl+0x20/0x38)
> > [] (vfs_ioctl) from [] (ksys_ioctl+0xbc/0x7b0)
> > [] (ksys_ioctl) from [] (ret_fast_syscall+0x0/0x54)
> > Exception stack(0xee8f3fa8 to 0xee8f3ff0)
> > 3fa0: 0005 adcbeb18 0005 c06864a2 adcbeb18
> > 0001
> > 3fc0: 0005 adcbeb18 c06864a2 0036 0029 0023 0023
> > 0007
> > 3fe0: b113b098 adcbeafc b1125413 b6155cf8
> > ---[ end trace 2ad5ba954ceb767a ]---
> > ---
> > drivers/gpu/drm/stm/ltdc.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
> > index 99bf93e8b36f..301de0498078 100644
> > --- a/drivers/gpu/drm/stm/ltdc.c
> > +++ b/drivers/gpu/drm/stm/ltdc.c
> > @@ -425,9 +425,12 @@ static void ltdc_crtc_atomic_enable(struct drm_crtc
> > *crtc,
> > struct drm_crtc_state *old_state)
> > {
> > struct ltdc_device *ldev = crtc_to_ltdc(crtc);
> > + struct drm_device *ddev = crtc->dev;
> >
> > DRM_DEBUG_DRIVER("\n");
> >
> > + pm_runtime_get_sync(ddev->dev);
> > +
> > /* Sets the background color value */
> > reg_write(ldev->regs, LTDC_BCCR, BCCR_BCBLACK);
> >
> >
> Hi Marek,
> Many thanks for your patch,
> Acked-by: Philippe Cornu
> Tested-by: Yannick Fertre
>
>
> Hi Benjamin,
> Could you please apply "drm/stm: ltdc: remove call of pm-runtime
> functions" **before** this one. Thank you.
Applied on drm-misc-next.
Thanks,
Benjamin
>
> Philippe :-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/stm: ltdc: remove call of pm-runtime functions
Le jeu. 2 juil. 2020 à 14:18, Philippe CORNU a écrit :
>
>
>
> On 7/1/20 2:04 PM, Yannick Fertre wrote:
> > It is not necessary to suspend or stop the ltdc clocks
> > to modify the pixel clock.
> >
> > Signed-off-by: Yannick Fertre
> > ---
> > drivers/gpu/drm/stm/ltdc.c | 16
> > 1 file changed, 16 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
> > index 3f590d916e91..6e28f707092f 100644
> > --- a/drivers/gpu/drm/stm/ltdc.c
> > +++ b/drivers/gpu/drm/stm/ltdc.c
> > @@ -506,15 +506,7 @@ static bool ltdc_crtc_mode_fixup(struct drm_crtc *crtc,
> >struct drm_display_mode *adjusted_mode)
> > {
> > struct ltdc_device *ldev = crtc_to_ltdc(crtc);
> > - struct drm_device *ddev = crtc->dev;
> > int rate = mode->clock * 1000;
> > - bool runtime_active;
> > - int ret;
> > -
> > - runtime_active = pm_runtime_active(ddev->dev);
> > -
> > - if (runtime_active)
> > - pm_runtime_put_sync(ddev->dev);
> >
> > if (clk_set_rate(ldev->pixel_clk, rate) < 0) {
> > DRM_ERROR("Cannot set rate (%dHz) for pixel clk\n", rate);
> > @@ -523,14 +515,6 @@ static bool ltdc_crtc_mode_fixup(struct drm_crtc *crtc,
> >
> > adjusted_mode->clock = clk_get_rate(ldev->pixel_clk) / 1000;
> >
> > - if (runtime_active) {
> > - ret = pm_runtime_get_sync(ddev->dev);
> > - if (ret) {
> > - DRM_ERROR("Failed to fixup mode, cannot get sync\n");
> > - return false;
> > - }
> > - }
> > -
> > DRM_DEBUG_DRIVER("requested clock %dkHz, adjusted clock %dkHz\n",
> >mode->clock, adjusted_mode->clock);
> >
> >
> Hi Yannick,
> Many thanks for your patch,
> Acked-by: Philippe Cornu
> Philippe :-)
Applied on drm-misc-next.
Thanks,
Benjamin
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/vgem: Do not allocate backing shmemfs file for an import dmabuf object
On Wed, Jul 08, 2020 at 11:22:00AM +0200, Christian König wrote: > Am 07.07.20 um 20:35 schrieb Chris Wilson: > > Quoting lepton (2020-07-07 19:17:51) > > > On Tue, Jul 7, 2020 at 10:20 AM Chris Wilson > > > wrote: > > > > Quoting lepton (2020-07-07 18:05:21) > > > > > On Tue, Jul 7, 2020 at 9:00 AM Chris Wilson > > > > > wrote: > > > > > > If we assign obj->filp, we believe that the create vgem bo is > > > > > > native and > > > > > > allow direct operations like mmap() assuming it behaves as backed > > > > > > by a > > > > > > shmemfs inode. When imported from a dmabuf, the obj->pages are > > > > > > not always meaningful and the shmemfs backing store misleading. > > > > > > > > > > > > Note, that regular mmap access to a vgem bo is via the dumb buffer > > > > > > API, > > > > > > and that rejects attempts to mmap an imported dmabuf, > > > > > What do you mean by "regular mmap access" here? It looks like vgem is > > > > > using vgem_gem_dumb_map as .dumb_map_offset callback then it doesn't > > > > > call > > > > > drm_gem_dumb_map_offset > > > > As I too found out, and so had to correct my story telling. > > > > > > > > By regular mmap() access I mean mmap on the vgem bo [via the dumb buffer > > > > API] as opposed to mmap() via an exported dma-buf fd. I had to look at > > > > igt to see how it was being used. > > > Now it seems your fix is to disable "regular mmap" on imported dma buf > > > for vgem. I am not really a graphic guy, but then the api looks like: > > > for a gem handle, user space has to guess to find out the way to mmap > > > it. If user space guess wrong, then it will fail to mmap. Is this the > > > expected way > > > for people to handle gpu buffer? > > You either have a dumb buffer handle, or a dma-buf fd. If you have the > > handle, you have to use the dumb buffer API, there's no other way to > > mmap it. If you have the dma-buf fd, you should mmap it directly. Those > > two are clear. > > > > It's when you import the dma-buf into vgem and create a handle out of > > it, that's when the handle is no longer first class and certain uAPI > > [the dumb buffer API in particular] fail. > > > > It's not brilliant, as you say, it requires the user to remember the > > difference between the handles, but at the same time it does prevent > > them falling into coherency traps by forcing them to use the right > > driver to handle the object, and have to consider the additional ioctls > > that go along with that access. > > Yes, Chris is right. Mapping DMA-buf through the mmap() APIs of an importer > is illegal. > > What we could maybe try to do is to redirect this mmap() API call on the > importer to the exporter, but I'm pretty sure that the fs layer wouldn't > like that without changes. We already do that, there's a full helper-ified path from I think shmem helpers through prime helpers to forward this all. Including handling buffer offsets and all the other lolz back&forth. Of course there's still the problem that many drivers don't forward the cache coherency calls for begin/end cpu access, so in a bunch of cases you'll cache cacheline dirt soup. But that's kinda standard procedure for dma-buf :-P But yeah trying to handle the mmap as an importer, bypassing the export: nope. The one exception is if you have some kind of fancy gart with cpu-visible pci bar (like at least integrated intel gpus have). But in that case the mmap very much looks&acts like device access in every way. Cheers, Daniel > Regards, > Christian. > > > > -Chris > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/vgem: Replace opencoded version of drm_gem_dumb_map_offset()
On Tue, Jul 07, 2020 at 05:00:12PM +0100, Chris Wilson wrote:
> drm_gem_dumb_map_offset() now exists and does everything
> vgem_gem_dump_map does and *ought* to do.
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/vgem/vgem_drv.c | 28 +---
> 1 file changed, 1 insertion(+), 27 deletions(-)
>
> diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c
> index eb3b7cdac941..866cff537f28 100644
> --- a/drivers/gpu/drm/vgem/vgem_drv.c
> +++ b/drivers/gpu/drm/vgem/vgem_drv.c
> @@ -236,32 +236,6 @@ static int vgem_gem_dumb_create(struct drm_file *file,
> struct drm_device *dev,
> return 0;
> }
>
> -static int vgem_gem_dumb_map(struct drm_file *file, struct drm_device *dev,
> - uint32_t handle, uint64_t *offset)
> -{
> - struct drm_gem_object *obj;
> - int ret;
> -
> - obj = drm_gem_object_lookup(file, handle);
> - if (!obj)
> - return -ENOENT;
> -
> - if (!obj->filp) {
> - ret = -EINVAL;
> - goto unref;
> - }
> -
> - ret = drm_gem_create_mmap_offset(obj);
> - if (ret)
> - goto unref;
> -
> - *offset = drm_vma_node_offset_addr(&obj->vma_node);
> -unref:
> - drm_gem_object_put_unlocked(obj);
> -
> - return ret;
> -}
> -
> static struct drm_ioctl_desc vgem_ioctls[] = {
> DRM_IOCTL_DEF_DRV(VGEM_FENCE_ATTACH, vgem_fence_attach_ioctl,
> DRM_RENDER_ALLOW),
> DRM_IOCTL_DEF_DRV(VGEM_FENCE_SIGNAL, vgem_fence_signal_ioctl,
> DRM_RENDER_ALLOW),
> @@ -455,7 +429,7 @@ static struct drm_driver vgem_driver = {
> .fops = &vgem_driver_fops,
>
> .dumb_create= vgem_gem_dumb_create,
> - .dumb_map_offset= vgem_gem_dumb_map,
> + .dumb_map_offset= drm_gem_dumb_map_offset,
Even better: Just delete it, it's the default. With that:
Reviewed-by: Daniel Vetter
Also maybe cc: stable, since this should stop the mmap attempts on
imported dma-buf? Or will this break stuff ...
-Daniel
>
> .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
> .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
> --
> 2.27.0
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] Host1x/TegraDRM UAPI (sync points)
On 7/7/20 2:06 PM, Dmitry Osipenko wrote: 02.07.2020 15:10, Mikko Perttunen пишет: Ok, so we would have two kinds of syncpoints for the job; one for kernel job tracking; and one that userspace can manipulate as it wants to. Could we handle the job tracking syncpoint completely inside the kernel, i.e. allocate it in kernel during job submission, and add an increment for it at the end of the job (with condition OP_DONE)? For MLOCKing, the kernel already needs to insert a SYNCPT_INCR(OP_DONE) + WAIT + MLOCK_RELEASE sequence at the end of each job. If sync point is allocated within kernel, then we'll need to always patch all job's sync point increments with the ID of the allocated sync point, regardless of whether firewall enabled or not. The idea was that the job tracking increment would also be added to the pushbuffer in the kernel, so gathers would only have increments for the "user syncpoints", if any. I think this should work for THI-based engines (e.g. VIC), you probably have better information about GR2D/GR3D. On newer Tegras we could use CHANNEL/APPID protection to prevent the gathers from incrementing these job tracking syncpoints. Secondly, I'm now recalling that only one sync point could be assigned to a channel at a time on newer Tegras which support sync point protection. So it sounds like we don't really have variants other than to allocate one sync point per channel for the jobs usage if we want to be able to push multiple jobs into channel's pushbuffer, correct? The other way around; each syncpoint can be assigned to one channel. One channel may have multiple syncpoints. ... Hmm, we actually should be able to have a one sync point per-channel for the job submission, similarly to what the current driver does! I'm keep forgetting about the waitbase existence! Tegra194 doesn't have waitbases, but if we are resubmitting all the jobs anyway, can't we just recalculate wait thresholds at that time? Yes, thresholds could be recalculated + job should be re-formed at the push-time then. It also means that jobs always should be formed only at the push-time if wait-command is utilized by cmdstream since the waits always need to be patched because we won't know the thresholds until scheduler actually runs the job. Could we keep the job tracking syncpoints entirely within the kernel, and have all wait commands and other stuff that userspace does use the user syncpoints? Then kernel job tracking and userspace activity would be separate from each other. Alternatively, if we know that jobs can only be removed from the middle of pushbuffers, and not added, we could replace any removed jobs with syncpoint increments in the pushbuffer and any thresholds would stay intact. Maybe a more detailed sequence list or diagram of what happens during submission and recovery would be useful. The textual form + code is already good enough to me. A diagram could be nice to have, although it may take a bit too much effort to create + maintain it. But I don't mind at all if you'd want to make one :) ... * We should be able to keep the syncpoint refcounting based on fences. The fence doesn't need the sync point itself, it only needs to get a signal when the threshold is reached or when sync point is ceased. Imagine: - Process A creates sync point - Process A creates dma-fence from this sync point - Process A exports dma-fence to process B - Process A dies What should happen to process B? - Should dma-fence of the process B get a error signal when process A dies? - Should process B get stuck waiting endlessly for the dma-fence? This is one example of why I'm proposing that fence shouldn't be coupled tightly to a sync point. As a baseline, we should consider process B to get stuck endlessly (until a timeout of its choosing) for the fence. In this case it is avoidable, but if the ID/threshold pair is exported out of the fence and is waited for otherwise, it is unavoidable. I.e. once the ID/threshold are exported out of a fence, the waiter can only see the fence being signaled by the threshold being reached, not by the syncpoint getting freed. This is correct. If sync point's FD is exported or once sync point is resolved from a dma-fence, then sync point will stay alive until the last reference to the sync point is dropped. I.e. if Process A dies *after* process B started to wait on the sync point, then it will get stuck. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 05/20] backlight: improve backlight_device documentation
On Fri, Jul 03, 2020 at 08:45:31PM +0200, Sam Ravnborg wrote: > Improve the documentation for backlight_device and > adapt it to kernel-doc style. > > The updated documentation is more strict on how locking is used. > With the update neither update_lock nor ops_lock may be used > outside the backlight core. > This restriction was introduced to keep the locking simple > by keeping it in the core. > It was verified that this documents the current state by renaming > update_lock => bl_update_lock and ops_lock => bl_ops_lock. > The rename did not reveal any uses outside the backlight core. > The rename is NOT part of this patch. > > v3: > - Update changelog to explain locking details (Daniel) > > v2: > - Add short intro to all fields (Daniel) > - Updated description of update_lock (Daniel) > > Signed-off-by: Sam Ravnborg > Reviewed-by: Emil Velikov > Cc: Lee Jones > Cc: Daniel Thompson > Cc: Jingoo Han Reviewed-by: Daniel Thompson Daniel. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 12/20] backlight: introduce backlight_get_brightness()
On Fri, Jul 03, 2020 at 08:45:38PM +0200, Sam Ravnborg wrote: > Based on an idea from Emil Velikov > add a helper that checks backlight_is_blank() and return 0 as brightness > if display is blank or the property value if not. > > This allows us to simplify the update_status() implementation > in most of the backlight drivers. > > Signed-off-by: Sam Ravnborg > Cc: Emil Velikov > Cc: Lee Jones > Cc: Daniel Thompson > Cc: Jingoo Han Reviewed-by: Daniel Thompson ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 2/4] dt-bindings: display: bridge: Add documentation for LT9611
Lontium LT9611 is a DSI to HDMI bridge which supports 2 DSI ports
and I2S port as input and one HDMI port as output
Reviewed-by: Rob Herring
Tested-by: John Stultz
Signed-off-by: Vinod Koul
---
.../display/bridge/lontium,lt9611.yaml| 176 ++
1 file changed, 176 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml
diff --git
a/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml
b/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml
new file mode 100644
index ..d60208359234
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml
@@ -0,0 +1,176 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/lontium,lt9611.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Lontium LT9611 2 Port MIPI to HDMI Bridge
+
+maintainers:
+ - Vinod Koul
+
+description: |
+ The LT9611 is a bridge device which converts DSI to HDMI
+
+properties:
+ compatible:
+enum:
+ - lontium,lt9611
+
+ reg:
+maxItems: 1
+
+ "#sound-dai-cells":
+const: 1
+
+ interrupts:
+maxItems: 1
+
+ reset-gpios:
+maxItems: 1
+description: GPIO connected to active high RESET pin.
+
+ vdd-supply:
+description: Regulator for 1.8V MIPI phy power.
+
+ vcc-supply:
+description: Regulator for 3.3V IO power.
+
+ ports:
+type: object
+
+properties:
+ "#address-cells":
+const: 1
+
+ "#size-cells":
+const: 0
+
+ port@0:
+type: object
+description: |
+ Primary MIPI port-1 for MIPI input
+
+properties:
+ reg:
+const: 0
+
+patternProperties:
+ "^endpoint(@[0-9])$":
+type: object
+additionalProperties: false
+
+properties:
+ remote-endpoint:
+$ref: /schemas/types.yaml#/definitions/phandle
+
+required:
+ - reg
+
+ port@1:
+type: object
+description: |
+ Additional MIPI port-2 for MIPI input, used in combination
+ with primary MIPI port-1 to drive higher resolution displays
+
+properties:
+ reg:
+const: 1
+
+patternProperties:
+ "^endpoint(@[0-9])$":
+type: object
+additionalProperties: false
+
+properties:
+ remote-endpoint:
+$ref: /schemas/types.yaml#/definitions/phandle
+
+required:
+ - reg
+
+ port@2:
+type: object
+description: |
+ HDMI port for HDMI output
+
+properties:
+ reg:
+const: 2
+
+patternProperties:
+ "^endpoint(@[0-9])$":
+type: object
+additionalProperties: false
+
+properties:
+ remote-endpoint:
+$ref: /schemas/types.yaml#/definitions/phandle
+
+required:
+ - reg
+
+required:
+ - "#address-cells"
+ - "#size-cells"
+ - port@0
+ - port@2
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - vdd-supply
+ - vcc-supply
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+
+i2c10 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ hdmi-bridge@3b {
+compatible = "lontium,lt9611";
+reg = <0x3b>;
+
+reset-gpios = <&tlmm 128 GPIO_ACTIVE_HIGH>;
+interrupts-extended = <&tlmm 84 IRQ_TYPE_EDGE_FALLING>;
+
+vdd-supply = <<9611_1v8>;
+vcc-supply = <<9611_3v3>;
+
+ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+reg = <0>;
+lt9611_a: endpoint {
+ remote-endpoint = <&dsi0_out>;
+};
+ };
+
+ port@1 {
+reg = <1>;
+lt9611_b: endpoint {
+ remote-endpoint = <&dsi1_out>;
+};
+ };
+
+ port@2 {
+reg = <2>;
+lt9611_out: endpoint {
+ remote-endpoint = <&hdmi_con>;
+};
+ };
+};
+ };
+};
+
+...
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 1/4] dt-bindings: vendor-prefixes: Add Lontium vendor prefix
Add prefix for Lontium Semiconductor Corporation Acked-by: Rob Herring Tested-by: John Stultz Signed-off-by: Vinod Koul --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 9aeab66be85f..31cdb21a3d22 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -595,6 +595,8 @@ patternProperties: description: Logic Technologies Limited "^longcheer,.*": description: Longcheer Technology (Shanghai) Co., Ltd. + "^lontium,.*": +description: Lontium Semiconductor Corporation "^loongson,.*": description: Loongson Technology Corporation Limited "^lsi,.*": -- 2.26.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 3/4] drm/bridge: Introduce LT9611 DSI to HDMI bridge
Lontium Lt9611 is a DSI to HDMI bridge which supports two DSI ports and
I2S port as an input and HDMI port as output
Co-developed-by: Bjorn Andersson
Signed-off-by: Bjorn Andersson
Co-developed-by: Srinivas Kandagatla
Signed-off-by: Srinivas Kandagatla
Tested-by: John Stultz
Signed-off-by: Vinod Koul
---
drivers/gpu/drm/bridge/Kconfig | 13 +
drivers/gpu/drm/bridge/Makefile |1 +
drivers/gpu/drm/bridge/lontium-lt9611.c | 1142 +++
3 files changed, 1156 insertions(+)
create mode 100644 drivers/gpu/drm/bridge/lontium-lt9611.c
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 43271c21d3fc..c7f0dacfb57a 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -48,6 +48,19 @@ config DRM_DISPLAY_CONNECTOR
on ARM-based platforms. Saying Y here when this driver is not needed
will not cause any issue.
+config DRM_LONTIUM_LT9611
+ tristate "Lontium LT9611 DSI/HDMI bridge"
+ select SND_SOC_HDMI_CODEC if SND_SOC
+ depends on OF
+ select DRM_PANEL_BRIDGE
+ select DRM_KMS_HELPER
+ select REGMAP_I2C
+ help
+ Driver for Lontium LT9611 DSI to HDMI bridge
+ chip driver that converts dual DSI and I2S to
+ HDMI signals
+ Please say Y if you have such hardware.
+
config DRM_LVDS_CODEC
tristate "Transparent LVDS encoders and decoders support"
depends on OF
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index d63d4b7e4347..7d7c123a95e4 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -2,6 +2,7 @@
obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o
obj-$(CONFIG_DRM_CHRONTEL_CH7033) += chrontel-ch7033.o
obj-$(CONFIG_DRM_DISPLAY_CONNECTOR) += display-connector.o
+obj-$(CONFIG_DRM_LONTIUM_LT9611) += lontium-lt9611.o
obj-$(CONFIG_DRM_LVDS_CODEC) += lvds-codec.o
obj-$(CONFIG_DRM_MEGACHIPS_STDP_GE_B850V3_FW) +=
megachips-stdp-ge-b850v3-fw.o
obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
diff --git a/drivers/gpu/drm/bridge/lontium-lt9611.c
b/drivers/gpu/drm/bridge/lontium-lt9611.c
new file mode 100644
index ..be0a47cce4d7
--- /dev/null
+++ b/drivers/gpu/drm/bridge/lontium-lt9611.c
@@ -0,0 +1,1142 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2018, The Linux Foundation. All rights reserved.
+ * Copyright (c) 2019-2020. Linaro Limited.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include
+#include
+#include
+#include
+#include
+
+#define EDID_SEG_SIZE 256
+#define EDID_LEN 32
+#define EDID_LOOP 8
+#define KEY_DDC_ACCS_DONE 0x02
+#define DDC_NO_ACK 0x50
+
+#define LT9611_4LANES 0
+
+struct lt9611 {
+ struct device *dev;
+ struct drm_bridge bridge;
+ struct drm_connector connector;
+
+ struct regmap *regmap;
+
+ struct device_node *dsi0_node;
+ struct device_node *dsi1_node;
+ struct mipi_dsi_device *dsi0;
+ struct mipi_dsi_device *dsi1;
+ struct platform_device *audio_pdev;
+
+ bool ac_mode;
+
+ struct gpio_desc *reset_gpio;
+ struct gpio_desc *enable_gpio;
+
+ bool power_on;
+ bool sleep;
+
+ struct regulator_bulk_data supplies[2];
+
+ struct i2c_client *client;
+
+ enum drm_connector_status status;
+
+ u8 edid_buf[EDID_SEG_SIZE];
+ u32 vic;
+};
+
+#define LT9611_PAGE_CONTROL0xff
+
+static const struct regmap_range_cfg lt9611_ranges[] = {
+ {
+ .name = "register_range",
+ .range_min = 0,
+ .range_max = 0x85ff,
+ .selector_reg = LT9611_PAGE_CONTROL,
+ .selector_mask = 0xff,
+ .selector_shift = 0,
+ .window_start = 0,
+ .window_len = 0x100,
+ },
+};
+
+static const struct regmap_config lt9611_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
+ .max_register = 0x,
+ .ranges = lt9611_ranges,
+ .num_ranges = ARRAY_SIZE(lt9611_ranges),
+};
+
+struct lt9611_mode {
+ u16 hdisplay;
+ u16 vdisplay;
+ u8 vrefresh;
+ u8 lanes;
+ u8 intfs;
+};
+
+static struct lt9611_mode lt9611_modes[] = {
+ { 3840, 2160, 30, 4, 2 }, /* 3840x2160 24bit 30Hz 4Lane 2ports */
+ { 1920, 1080, 60, 4, 1 }, /* 1080P 24bit 60Hz 4lane 1port */
+ { 1920, 1080, 30, 3, 1 }, /* 1080P 24bit 30Hz 3lane 1port */
+ { 1920, 1080, 24, 3, 1 },
+ { 720, 480, 60, 4, 1 },
+ { 720, 576, 50, 2, 1 },
+ { 640, 480, 60, 2, 1 },
+};
+
+static struct lt9611 *bridge_to_lt9611(struct drm_bridge *bridge)
+{
+ return container_of(bridge, struct lt9611, bridge);
+}
+
+static int lt9611_mipi_input_analog(struct lt9611 *lt9611)
+{
+ const struct reg_sequence reg_cfg[] = {
+ { 0x8106, 0x40 }, /* port A rx current */
+ { 0x
[PATCH v5 4/4] drm/msm/dsi: attach external bridge with DRM_BRIDGE_ATTACH_NO_CONNECTOR
Modern bridges do not create the connector and expect the display driver
to do so. Hence, create the drm connector in msm display driver and add
use flag DRM_BRIDGE_ATTACH_NO_CONNECTOR to attach bridges
Tested-by: John Stultz
Signed-off-by: Vinod Koul
---
drivers/gpu/drm/msm/dsi/dsi.c | 7 +--
drivers/gpu/drm/msm/dsi/dsi_manager.c | 27 +--
2 files changed, 14 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/msm/dsi/dsi.c b/drivers/gpu/drm/msm/dsi/dsi.c
index 55ea4bc2ee9c..617075e3e3f0 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.c
+++ b/drivers/gpu/drm/msm/dsi/dsi.c
@@ -219,12 +219,7 @@ int msm_dsi_modeset_init(struct msm_dsi *msm_dsi, struct
drm_device *dev,
goto fail;
}
- /*
-* check if the dsi encoder output is connected to a panel or an
-* external bridge. We create a connector only if we're connected to a
-* drm_panel device. When we're connected to an external bridge, we
-* assume that the drm_bridge driver will create the connector itself.
-*/
+ /* Initialize the internal panel or external bridge */
ext_bridge = msm_dsi_host_get_bridge(msm_dsi->host);
if (ext_bridge)
diff --git a/drivers/gpu/drm/msm/dsi/dsi_manager.c
b/drivers/gpu/drm/msm/dsi/dsi_manager.c
index 4b363bd7ddff..72cfd0a8187b 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_manager.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_manager.c
@@ -3,6 +3,7 @@
* Copyright (c) 2015, The Linux Foundation. All rights reserved.
*/
+#include
#include "msm_kms.h"
#include "dsi.h"
@@ -689,7 +690,7 @@ struct drm_bridge *msm_dsi_manager_bridge_init(u8 id)
bridge = &dsi_bridge->base;
bridge->funcs = &dsi_mgr_bridge_funcs;
- ret = drm_bridge_attach(encoder, bridge, NULL, 0);
+ ret = drm_bridge_attach(encoder, bridge, NULL,
DRM_BRIDGE_ATTACH_NO_CONNECTOR);
if (ret)
goto fail;
@@ -709,7 +710,6 @@ struct drm_connector *msm_dsi_manager_ext_bridge_init(u8 id)
struct drm_encoder *encoder;
struct drm_bridge *int_bridge, *ext_bridge;
struct drm_connector *connector;
- struct list_head *connector_list;
int_bridge = msm_dsi->bridge;
ext_bridge = msm_dsi->external_bridge =
@@ -717,22 +717,21 @@ struct drm_connector *msm_dsi_manager_ext_bridge_init(u8
id)
encoder = msm_dsi->encoder;
- /* link the internal dsi bridge to the external bridge */
- drm_bridge_attach(encoder, ext_bridge, int_bridge, 0);
-
- /*
-* we need the drm_connector created by the external bridge
-* driver (or someone else) to feed it to our driver's
-* priv->connector[] list, mainly for msm_fbdev_init()
+ /* link the internal dsi bridge to the external bridge and attach
+* the connector, we are supporting DRM_BRIDGE_ATTACH_NO_CONNECTOR
+* so always create connector
*/
- connector_list = &dev->mode_config.connector_list;
+ drm_bridge_attach(encoder, ext_bridge, int_bridge,
DRM_BRIDGE_ATTACH_NO_CONNECTOR);
- list_for_each_entry(connector, connector_list, head) {
- if (drm_connector_has_possible_encoder(connector, encoder))
- return connector;
+ connector = drm_bridge_connector_init(dev, encoder);
+ if (IS_ERR(connector)) {
+ DRM_DEV_ERROR(dev->dev, "drm_bridge_connector_init failed:
%ld\n",
+ PTR_ERR(connector));
+ return ERR_PTR(-ENODEV);
}
- return ERR_PTR(-ENODEV);
+ drm_connector_attach_encoder(connector, msm_dsi->encoder);
+ return connector;
}
void msm_dsi_manager_bridge_destroy(struct drm_bridge *bridge)
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 0/4] Add LT9611 DSI to HDMI bridge
Hi, This series adds driver and bindings for Lontium LT9611 bridge chip which takes MIPI DSI as input and HDMI as output. This chip can be found in 96boards RB3 platform [1] commonly called DB845c. [1]: https://www.96boards.org/product/rb3-platform/ Changes in v5: - make symbol static, reported by kbuild-bot Changes in v4: - Add msm/dsi patch to create connector and support DRM_BRIDGE_ATTACH_NO_CONNECTOR - Fix comments provided by Sam Changes in v3: - fix kbuild reported error - rebase on v5.8-rc1 Changes in v2: - Add acks by Rob - Fix comments reported by Emil and rename the file to lontium-lt9611.c - Fix comments reported by Laurent on binding and driver - Add HDMI audio support Vinod Koul (4): dt-bindings: vendor-prefixes: Add Lontium vendor prefix dt-bindings: display: bridge: Add documentation for LT9611 drm/bridge: Introduce LT9611 DSI to HDMI bridge drm/msm/dsi: attach external bridge with DRM_BRIDGE_ATTACH_NO_CONNECTOR .../display/bridge/lontium,lt9611.yaml| 176 +++ .../devicetree/bindings/vendor-prefixes.yaml |2 + drivers/gpu/drm/bridge/Kconfig| 13 + drivers/gpu/drm/bridge/Makefile |1 + drivers/gpu/drm/bridge/lontium-lt9611.c | 1142 + drivers/gpu/drm/msm/dsi/dsi.c |7 +- drivers/gpu/drm/msm/dsi/dsi_manager.c | 27 +- 7 files changed, 1348 insertions(+), 20 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml create mode 100644 drivers/gpu/drm/bridge/lontium-lt9611.c -- 2.26.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 14/20] backlight: cr_bllcd: introduce backlight_is_blank()
On Fri, Jul 03, 2020 at 08:45:40PM +0200, Sam Ravnborg wrote:
> The cr_bllcd uses the FB_BLANK states as brightness.
> This results in brightness value equals 0 that turn on
> the display and 4 that turn off the display.
max_brightness is 0 which makes it impossible to set the brightness to
4.
> Simplify the logic but keep current behaviour
> as userspace may expect brightness set to 0 to turn on the display.
I don't deny the possibility but we'd be talking about a userspace
custom enough to explicitly configure the module loader (otherwise
the module wouldn't load and the backlight would be inherited from
the BIOS) and that also contains an explicit write to the brightness
property that sets it to what is already the default (and only
possible) value.
In other words I'm very sceptical such a userspace exists and would be
happy to see this driver modified to use the new helpers and behave
like gpio-backlight (which can be regarded as our reference 1-bit
backlight driver).
Daniel.
>
> Signed-off-by: Sam Ravnborg
> Cc: Lee Jones
> Cc: Daniel Thompson
> Cc: Jingoo Han
> ---
> drivers/video/backlight/cr_bllcd.c | 14 --
> 1 file changed, 4 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/video/backlight/cr_bllcd.c
> b/drivers/video/backlight/cr_bllcd.c
> index 4624b7b7c6a6..edca5fee9689 100644
> --- a/drivers/video/backlight/cr_bllcd.c
> +++ b/drivers/video/backlight/cr_bllcd.c
> @@ -63,22 +63,16 @@ static int cr_backlight_set_intensity(struct
> backlight_device *bd)
> u32 addr = gpio_bar + CRVML_PANEL_PORT;
> u32 cur = inl(addr);
>
> - if (bd->props.power == FB_BLANK_UNBLANK)
> - intensity = FB_BLANK_UNBLANK;
> - if (bd->props.fb_blank == FB_BLANK_UNBLANK)
> - intensity = FB_BLANK_UNBLANK;
> - if (bd->props.power == FB_BLANK_POWERDOWN)
> - intensity = FB_BLANK_POWERDOWN;
> - if (bd->props.fb_blank == FB_BLANK_POWERDOWN)
> + if (backlight_is_blank(bd))
> intensity = FB_BLANK_POWERDOWN;
>
> - if (intensity == FB_BLANK_UNBLANK) { /* FULL ON */
> + if (intensity != FB_BLANK_POWERDOWN) { /* FULL ON */
> cur &= ~CRVML_BACKLIGHT_OFF;
> outl(cur, addr);
> - } else if (intensity == FB_BLANK_POWERDOWN) { /* OFF */
> + } else { /* OFF */
> cur |= CRVML_BACKLIGHT_OFF;
> outl(cur, addr);
> - } /* anything else, don't bother */
> + }
>
> return 0;
> }
> --
> 2.25.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 15/20] backlight: gpio_backlight: simplify update_status()
On Fri, Jul 03, 2020 at 08:45:41PM +0200, Sam Ravnborg wrote: > Introduce the use of backlight_get_brightness() to simplify > the update_status() operation. > With the simpler implementation drop the gpio_backlight_get_next_brightness() > helper as it was now a one-liner. > > Signed-off-by: Sam Ravnborg > Cc: Lee Jones > Cc: Daniel Thompson > Cc: Jingoo Han Reviewed-by: Daniel Thompson ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 16/20] backlight: jornada720_bl: introduce backlight_is_blank()
On Fri, Jul 03, 2020 at 08:45:42PM +0200, Sam Ravnborg wrote: > Use the backlight_is_blank() helper to simplify the code a bit. > This add support for fb_blank as a side-effect. > > Signed-off-by: Sam Ravnborg > Cc: Lee Jones > Cc: Daniel Thompson > Cc: Jingoo Han This driver exhibits the "how does userspace know what writing brightness zero to sysfs actually does" problem so can't use the backlight_get_brightness() helper. If you respin it would be good to see that in the patch description but that's such an extreme nitpick It think, either way, this can be: Reviewed-by: Daniel Thompson Daniel. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 17/20] backlight: use backligt_get_brightness()
On Fri, Jul 03, 2020 at 08:45:43PM +0200, Sam Ravnborg wrote: > Introduce the backlight_get_brightness() helper in all > video/backlight/* drivers. > This simplifies the code and align the implementation of the > update_status() operation across the different backlight drivers. > > Some of the drivers gains a little extra functionality by the change > as they now respect the fb_blank() ioctl. > > Signed-off-by: Sam Ravnborg Reviewed-by: Daniel Thompson Daniel. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 19/20] backlight: make of_find_backlight static
On Fri, Jul 03, 2020 at 08:45:45PM +0200, Sam Ravnborg wrote: > There are no external users of of_find_backlight, > as they have all changed to use the managed version. > Make of_find_backlight static to prevent new external users. > > v3: > - Move doc for devm_of_find_backlight out of this patch > > v2: > - Editorial corrections (Daniel) > - Returns => RETURNS (Daniel) > > Signed-off-by: Sam Ravnborg > Cc: Lee Jones > Cc: Daniel Thompson > Cc: Jingoo Han Reviewed-by: Daniel Thompson Daniel. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 208413] amdgpu driver crash
https://bugzilla.kernel.org/show_bug.cgi?id=208413 --- Comment #3 from ghutzr...@gmail.com --- I can't say with certainty, because the crashes were quite irregular, but I have more than 10 hours of continuous usage without any gpu driver crashes on 5.8.rc4. -- 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: drm/ast something ate high-res modes (5.3->5.6 regression)
Hi Am 08.07.20 um 12:05 schrieb Ilpo Järvinen: > Hi, > > After upgrading kernel from 5.3 series to 5.6.16 something seems to > prevent me from achieving high resolutions with the ast driver. Thanks for reporting. It's not a bug, but a side effect of atomic modesetting. During pageflips, the old code used to kick out the currently displayed framebuffer and then load in the new one. If that failed, the display went garbage. In v5.6-rc1, we merged atomic modesetting for ast. This means that screen updates are more reliable, but we have to over-commit resources. Specifically, we have to reserve space for two buffers in video memory while a pageflip happens. 1920x1200@32 are ~9MiB of framebuffer memory. If your device has 16 MiB of VRAM, there's no space left for the second framebuffer. Hence, the resolution is no longer supported. On the positive side, you can now use Wayland compositors with ast. Atomic modesetting adds the necessary interfaces. Best regards Thomas > > With 5.6.16: > > $ xrandr > Screen 0: minimum 320 x 200, current 1600 x 1200, maximum 1920 x 2048 > VGA-1 connected primary 1600x1200+0+0 (normal left inverted right x axis y > axis) 519mm x 324mm >1600x1200 60.00* >1680x1050 59.95 >1280x1024 75.0260.02 >1440x900 59.89 >1280x800 59.81 >1024x768 75.0360.00 >800x600 75.0060.32 >640x480 75.0059.94 >1920x1200_60.0 59.95 > > If I try to change to that manually added high-res mode, I get: > xrandr: Configure crtc 0 failed > > With 5.3 series I've this: > > Screen 0: minimum 320 x 200, current 1920 x 1200, maximum 1920 x 2048 > VGA-1 connected primary 1920x1200+0+0 (normal left inverted right x axis y > axis) 519mm x 324mm >1920x1200 59.95*+ >1600x1200 60.00 >1680x1050 59.95 >1280x1024 75.0260.02 >1440x900 59.89 >1280x800 59.81 >1024x768 75.0360.00 >800x600 75.0060.32 >640x480 75.0059.94 >1920x1200_60.0 59.95 > > As I've had issues in getting EDID reliably from the monitor, I provide it > on kernel command-line (the one dumped from the monitor I use). In > addition, I've another workaround for past issues related to EDID which > always adds that 1920x1200_60.0 mode but now I cannot use even it to > enter a high-res mode. > > If you need some additional info or want me to test a patch, just let me > know (but some delay is expected in testing patches). Thanks. > > -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer signature.asc Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] drm-misc-fixes
Hi Dave and Daniel, here's the PR for the current drm-misc-fixes. Only two patches this week. drm-misc-fixes-2020-07-08: * meson: OSD burst-length fixes * hibmc: fix runtime warning by setting up generic fbdev after registering device The following changes since commit bda8eaa6dee7525f4dac950810a85a88bf6c2ba0: drm: sun4i: hdmi: Remove extra HPD polling (2020-06-30 10:01:48 +0200) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2020-07-08 for you to fetch changes up to 00debf8109e5fad3db31375be2a3c515e1461b4a: drm/hisilicon/hibmc: Move drm_fbdev_generic_setup() down to avoid the splat (2020-07-08 09:08:22 +) * meson: OSD burst-length fixes * hibmc: fix runtime warning by setting up generic fbdev after registering device Martin Blumenstingl (1): drm/meson: viu: fix setting the OSD burst length in VIU_OSD1_FIFO_CTRL_STAT Zenghui Yu (1): drm/hisilicon/hibmc: Move drm_fbdev_generic_setup() down to avoid the splat drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 5 +++-- drivers/gpu/drm/meson/meson_registers.h | 6 ++ drivers/gpu/drm/meson/meson_viu.c | 11 ++- 3 files changed, 11 insertions(+), 11 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/1] video: backlight: sky81452-backlight: Fix some kerneldoc issues
Firstly, all lines must begin with a '*'. Secondly, arg descriptions
must be spelt correctly, so fix misspelling of 'gpioD_enable' and
'short_detecTion_threshold'
Fixes the following W=1 kernel build warning(s):
drivers/video/backlight/sky81452-backlight.c:46: warning: bad line:
If it is not defined, default name is lcd-backlight.
drivers/video/backlight/sky81452-backlight.c:64: warning: Function parameter
or member 'gpiod_enable' not described in 'sky81452_bl_platform_data'
drivers/video/backlight/sky81452-backlight.c:64: warning: Function parameter
or member 'short_detection_threshold' not described in
'sky81452_bl_platform_data'
Cc: Daniel Thompson
Cc: Jingoo Han
Cc: Bartlomiej Zolnierkiewicz
Cc: Gyungoh Yoo
Cc: dri-devel@lists.freedesktop.org
Cc: linux-fb...@vger.kernel.org
Signed-off-by: Lee Jones
---
drivers/video/backlight/sky81452-backlight.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/video/backlight/sky81452-backlight.c
b/drivers/video/backlight/sky81452-backlight.c
index 83ccb3d940fae..0ce1815850080 100644
--- a/drivers/video/backlight/sky81452-backlight.c
+++ b/drivers/video/backlight/sky81452-backlight.c
@@ -43,13 +43,13 @@
/**
* struct sky81452_platform_data
* @name: backlight driver name.
- If it is not defined, default name is lcd-backlight.
- * @gpios_enable:GPIO descriptor which control EN pin
+ * If it is not defined, default name is lcd-backlight.
+ * @gpiod_enable:GPIO descriptor which control EN pin
* @enable:Enable mask for current sink channel 1, 2, 3, 4, 5 and 6.
* @ignore_pwm:true if DPWMI should be ignored.
* @dpwm_mode: true is DPWM dimming mode, otherwise Analog dimming mode.
* @phase_shift:true is phase shift mode.
- * @short_detecion_threshold: It should be one of 4, 5, 6 and 7V.
+ * @short_detection_threshold: It should be one of 4, 5, 6 and 7V.
* @boost_current_limit: It should be one of 2300, 2750mA.
*/
struct sky81452_bl_platform_data {
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
